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Executive  Summary 


The  purpose  of  this  technical  note  is  to  help  people  who  are  familiar  with  the  DoD’s  “Traditional 
World”  of  waterfall-based  software  development  understand  the  terms,  tasks  and  phases  that  are 
used  in  the  “Agile  World”  of  Agile  software  development  methods.  The  technical  note  should 
also  assist  those  readers  who  are  more  familiar  with  Agile  software  development  methods  better 
understand  the  DoD  environment. 

The  technical  note  does  not  champion  either  development  approach,  but  rather  provides  a  Rosetta 
Stone'  to  help  practitioners  familiar  with  either  development  approach  better  understand  the  lan¬ 
guage  used  by  the  other.  Nor  does  the  technical  note  claim  that  the  approaches  are  equivalent — 
only  similar  in  that  they  use  the  same  building  blocks  (but  use  them  differently). 

The  first  section  of  the  technical  note  provides  background  material.  It  provides  an  overview  of 
the  waterfall  software  development  method  as  well  as  a  discussion  of  how  this  came  to  be  the 
foundation  of  DoD’s  “traditional”  approach  to  developing  software  systems.^  This  section  goes  on 
to  provide  an  overview  of  Agile  software  development  methods. 

The  second  section  of  the  technical  note  discusses  some  of  the  similarities  between  the  Traditional 
World  and  the  Agile  World.  The  third  section  of  the  report  is  devoted  to  a  single  discussion  of  a 
philosophical  distinction  between  the  Traditional  World  and  the  Agile  World. 

The  fourth  section  of  the  technical  note  is  a  series  of  tables  describing  25  select  Traditional  World 
and  Agile  terms.  Each  table  defines  the  term  or  concept,  describes  where  it  might  be  used,  and 
identifies  associated  terms  or  concepts. 

The  technical  note  concludes  with  a  summary  and  an  appendix  which  provide  greater  detail  about 
the  origins  of  the  waterfall  software  development  method  and  its  history  in  DoD. 

The  authors  hope  that  this  technical  note  stimulates  discussions  among  practitioners  in  both  the 
Agile  community  and  the  waterfall  community  so  that  terms  and  definitions  can  be  added,  updat¬ 
ed,  or  removed  as  needed. 


The  Rosetta  Stone  (Egypt,  Ptolemaic  Period,  196  BC)  is  a  decree  inscribed  in  a  stone  written  in  three  scripts 
(hieroglyphic,  demotic,  and  Greek);  because  it  was  the  same  decree  written  in  multiple  languages,  it  was  an  in¬ 
valuable  key  to  deciphering  the  hieroglyphs. 

We  understand  that  the  waterfall  paradigm  has  morphed  since  it  was  first  conceived  in  the  1970s,  with  the  sys¬ 
tem  engineering  V  diagram  emerging  as  one  of  the  most  widely-used  variants.  For  the  purposes  of  this  paper, 
however,  we  will  use  the  term  waterfall  to  characterize  this  approach. 
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Abstract 


This  technical  note  (TN)  is  part  of  the  Software  Engineering  Institute’s  series  on  Agile  in  the  De¬ 
partment  of  Defense  (DoD).  It  primarily  addresses  what  at  first  seems  a  small  issue  on  the  road  to 
Agile  adoption — ^the  confusion  of  terms.  However,  this  is  a  much  larger  issue,  as  ineffective 
communications  among  and  between  stakeholders  is  often  cited  as  a  significant  stumbling  block 
on  any  project.^  Confusion  over  simple  terms  is  a  needless  hurdle. 

Many  terms  and  concepts  used  by  Agile  practitioners  seem  to  confound  those  working  in  the 
DoD’s  Traditional  World  of  waterfall-based  environment,  and  vice  versa.  The  goal  of  this  paper  is 
to  assemble  terms  and  concepts  from  both  environments  to  show  both  the  similarities  (of  which 
there  are  many)  and  differences  (of  which  there  are  also  many). 

A  comprehensive  cross  dictionary  was  beyond  the  scope  of  this  work;  the  authors  strove  to  select 
from  those  terms  most  commonly  encountered  when  considering  Agile  adoption.  Therefore,  the 
authors  selected  terms  based  on  suggestions  from  both  inside  and  outside  the  SEI,  but  deliberately 
limited  themselves  to  25  terms  from  each  environment. 


Poor  Communications,  Unrealistic  Scheduling  Lead  To  IT  Project  Failure;  K.C.  Jones,  Information  Week; 
http://www.informationweek.eom/poor-communications-unrealistic-scheduli/198000251 
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Introduction 


Developing  software  using  the  waterfall  paradigm  or  one  of  its  derivatives  has  become  so  en¬ 
twined  with  the  Department  of  Defense  (DoD)  acquisition  system  (at  least  in  perception)  that  it  is 
often  difficult  to  pry  them  apart.  In  light  of  that,  it  is  the  combination  of  these  two  spheres  that  we 
call  the  “Traditional  World”  in  this  technical  note. 

This  means  that  the  Traditional  World  is  not  just  the  waterfall  software  development  methodology 
itself  but  is  the  entire  environment,  laws,  and  regulations  that  have  grown  up  around  it.  This  in¬ 
cludes  the  acquisition  community,  the  requirements  community,  the  test  community,  the  man¬ 
agement  community,  the  development  community,  the  oversight  community,  and  the  like. 

These  stakeholders  are  the  target  audience  for  this  report.  In  light  of  the  DoD’s  recent  emphasis 
on  incorporating  Agile  software  development  methods  into  this  environment,  our  goal  is  to  help 
people  familiar  with  the  Traditional  World  understand  the  terms  and  concepts  of  the  “Agile 
World.”  We  also  include  a  short  description  of  the  Traditional  World  to  help  Agile  practitioners 
who  may  be  unfamiliar  with  its  history  and  concepts. 

We  will  point  out  similarities  and  differences  between  the  two  methods  (Traditional  and  Agile). 
The  similarities  in  terms  are  not  exact  in  most  cases  but  only  likenesses  in  each  world.  The  paral¬ 
lels  we  draw  we  hope  can  be  used  to  help  dispel  the  fear  of  the  unknown  which  could  lead  to  re¬ 
jection. 

Section  1  begins  with  a  brief  overview  of  the  waterfall  design  methodology  as  well  as  some  con¬ 
text  as  to  how  it  became  to  be  the  Department  of  Defense’s  tradition.  We  describe  the  waterfall 
development  methodology  separately  from  the  DoD  acquisition  process,  for  they  are  indeed  com¬ 
pletely  separate.  However,  for  the  dictionary  tables  that  follow  we  included  a  number  of  DoD  ac¬ 
quisition-related  and  systems  engineering-related  terms  as  we  feel  they  are  critical  to  our  goal  for 
this  work.  Some  examples  of  these  DoD  acquisition  or  system  engineering-related  terms  are 
“earned  value  management”  and  “critical  path”  as  well  as  other  terms  and  jargon  such  as  “ball 
park  estimate”. 

Section  1  continues  with  a  brief  overview  of  the  Agile  development  methodologies,  with  an  em¬ 
phasis  on  extreme  programming  (XP)  and  Scram  expressions  as  they  represent  two  of  the  most 
prevalent  Agile  methods. 

Section  2  is  a  high-level  discussion  of  some  of  the  similarities  between  the  Traditional  World  and 
the  Agile  World.  It  primarily  focuses  on  the  observation  that  both  the  Traditional  World  and  the 
Agile  World — as  with  all  software  development  methods — ^use  the  same  basic  building  blocks, 
such  as  requirements,  test,  design,  etc. 

Section  3  goes  on  to  observe  that  while  the  basic  building  blocks  are  the  same,  the  two  worlds  are 
separated  by  appreciably  different  perspectives  on  how  these  building  blocks  are  used. 

Section  4  is  a  Traditional-to-Agile  and  an  Agile-to-Traditional  dictionary  to  assist  practitioners  of 
both  methodologies  understand  the  terms  used  by  the  other. 
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Section  5  is  a  summary  of  the  technical  note. 

In  creating  this  document,  the  SEI  drew  from  a  number  of  sources  including  but  not  limited  to 
these  documents  and  websites: 

1 .  DA  U  Glossary  of  Defense  Acquisition  Acronyms  and  Terms,  14th  Edition,  July  2011 

2.  http://www.aspe-sdlc.com;  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Methods 

3.  ISA/IEC/IEEE  24765  Systems  and  Software  engineering  -  Vocabulary;  December  15,  2010 

4.  http://www.telerik.com/agile-project-management-tools/agile-resources/vocabulary.aspx 

5.  PMBOK  Guide®  —  Third  Edition 

6.  http://www.accurev.com/wiki/agile-glosssary 

7.  http://www.develop.com/agiledemystified 

8.  http://xprogramming.com/book/whatisxp/ 


CMU/SEI-2013-TN-021 


1  The  Two  Worlds — Traditional  and  Agile 


1.1  Background 

The  DoD  has  a  long  history  with  software  development,  including  a  number  of  techniques  that  in 
today’s  parlance  would  be  considered  “Agile”  or  even  “extreme.”  As  with  all  emerging  technolo¬ 
gies  however,  software  engineering  has  had  its  share  of  issues,  in  part  due  to  the  heavy  influence 
of  hardware-oriented  development  approaches  on  software  development.  In  response  to  the 
“software  crisis”  of  the  late  1960s  DoD  took  steps  designed  to  control  the  development  of  com¬ 
plex  software-intensive  systems"'. 

As  one  example,  in  the  1970’s  DoD  created  Ada  to  serve  as  a  department-wide  standard  pro¬ 
gramming  language  to  satisfy  the  Department’s  requirements  for  embedded  and  mission-critical 
software.  DoD  also  hoped  that  Ada  would  encourage  good  software  engineering.^ 

For  a  variety  of  reasons  that  seemed  sound  at  the  time,  DoD  began  issuing  a  series  of  standards 
and  policies  that  discounted  or  moved  away  from  its  more-Agile  experiences,  instead  pushing  a 
rigidly  sequential,  big  design  up  front  (BDUF),  big  test  at  the  end,  “document  everything”  ap¬ 
proach. 

This  approach  came  to  be  called  waterfall  due  to  several  common  graphical  representations  of  the 
approach.  Even  at  its  inception,  however,  many  experts  cautioned  that  the  notion  that  DoD’s 
large,  complex  software  development  efforts  could  be  controlled  with  a  rigidly-controlled,  docu¬ 
ment-intensive  and  review-intensive  approach  would  not  work.  There  is  some  irony  in  that  a  simi¬ 
lar  message  was  very  visible  in  popular  culture  at  the  time: 

"The  more  you  tighten  your  grip,  Tarkin,  the  more  star  systems  will  slip 
through  your  fingers.^” 

Flistory  has  unfortunately  proven  these  cautions  to  be  correct.  It  is  hue  that  projects  and  programs 
using  the  DoD  acquisition  paradigm  and  waterfall  software  development  methods  (i.e.,  the  Tradi¬ 
tional  World  as  we  have  defined  it)  have  delivered  solid  and  even  sometimes  spectacular  results. 
Flowever,  it  is  also  true  that  the  word  “spectacular”  was  often  used  to  describe  a  waterfall  failure, 
not  a  success. 

DoD  did  in  fact  begin  backing  away  from  waterfall  almost  as  soon  as  it  issued  the  initial  man¬ 
dates.^  Even  the  term  waterfall  has  not  been  officially  used  in  DoD  for  a  number  of  years.*  Even 


■'  For  a  brief  description  of  this,  piease  see  Appendix  A. 

^  Committee  on  the  Past  and  Present  Contexts  for  the  Use  of  Ada  in  the  Department  of  Defense,  Nationai  Re¬ 
search  Councii.  "The  Changing  Context  for  DOD  Software  Deveiopment."  Ada  and  Beyond:  Software  Poiicies 
for  the  Department  of  Defense.  Washington,  DC:  The  Nationai  Academies  Press,  1997 

®  Princess  Leia  to  Grand  Moff  Tarkin;  Star  Wars:  Episode  IV- A  New  Hope  (1977) 

^  in  1986,  a  draft  copy  of  Revision  A  to  MiL-STD  2167  appeared  which  removed  the  emphasis  on  top-down  de¬ 
sign  and  caiied  out  rapid  prototyping  as  an  aiternative  to  the  waterfaii. 

®  Acquisition  Strategy  Considerations,  2000  Department  of  Defense  Instruction  Number  5000.2;  October  23, 
2000;  the  term  waterfaii  is  not  used  but  is  caiied  a  “singie  step  to  fuii  capabiiity.” 
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with  this,  however,  waterfall  software  development  methodology  continued  to  be  a  major — if  not 
the  dominant — influence  on  DoD  software  acquisition  and  development. 

It  was  in  part  a  reaction  to  the  “analysis  paralysis”  and  other  waterfall  issues  that  gave  rise  to  the 
movement  we  now  call  Agile.  In  writing  about  the  Agile  Manifesto’s  origins,  Jim  Highsmith  says 
the  group  was  driven  by  “the  need  for  an  alternative  to  documentation  driven,  heavyweight  soft¬ 
ware  development  processes”  — which  is  how  the  waterfall  methodology  was  (and  is)  frequently 
characterized  [Highsmith  2001].  The  Agile  Manifesto  is  a  short  philosophical  summary  of  the 
group’s  values  regarding  software  development  [Beck  2001]: 

•  Individuals  and  interactions  are  valued  more  than  processes  and  tools. 

•  Working  software  is  valued  more  than  comprehensive  documentation. 

•  Customer  collaboration  is  valued  more  than  contract  negotiation. 

•  Responding  to  change  is  valued  more  than  following  a  plan. 

There  is  no  hiding  that  if  you  over-emphasize  wrong  aspects  of  process  and  tools,  comprehensive 
documentation,  contract  negotiation,  and  following  a  plan  you  will  have  the  worst  of  waterfall. 

On  the  other  hand,  if  you  over-emphasize  wrong  aspects  of  individuals  and  interactions,  working 
software,  customer  coloration,  and  responding  to  change  you  will  have  “cowboy  coding” — a  fre¬ 
quent  but  erroneous  characterization  of  Agile.  An  incorrect  emphasis  on  the  left-hand  side  of 
each  statement  would  also  not  be  successful  in  the  DoD  environment.  The  right  side  is  still  of  val¬ 
ue  and  if  completely  ignored  the  development  effort  will  fail.  This  is  central  to  the  debate  about 
Agile  scalability — a  balance  between  the  two  must  be  maintained.^ 

Highsmith  went  on  to  say: 

The  Agile  movement  is  not  anti-methodology;  in  fact,  many  of  us  want  to  re¬ 
store  credibility  to  the  word  methodology. 

We  want  to  restore  a  balance. 

We  embrace  modeling,  but  not  in  order  to  file  some  diagram  in  a  dusty  corpo¬ 
rate  repository. 

We  embrace  documentation,  but  not  hundreds  of pages  of  never-maintained 
and  rarely-used  tomes. 

We  plan,  but  recognize  the  limits  of  planning  in  a  turbulent  environment. 

Those  who  would  brand  proponents  ofXP  or  Scrum  or  any  of  the  other  Agile 
Methodologies  as  "hackers"  are  ignorant  of  both  the  methodologies  and  the 
original  definition  of  the  term  hacker. 

As  Highsmith  implied  and  we  agree,  the  new  world  of  Agile  methods  and  the  Traditional  World’s 
waterfall-based  methods  are  not  opposites;  they  are  just  different  perspectives  which  place  differ- 


Agile  scalability  is  a  topic  of  much  interest,  research,  and  debate  and  it  beyond  the  scope  of  this  report;  howev¬ 
er  it  is  an  important  enough  issue  that  we  felt  the  need  to  acknowledge  it. 
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ent  emphasis  on  similar  parts.  Depending  on  the  project’s  needs,  a  combination  of  both  methods 
may  be  most  appropriate.  It  does  not  have  to  be  an  either-or  proposition. 

Surprisingly,  we  did  not  discover  much  material  exploring  the  concept  that  Agile  methods  and 
Traditional  waterfall  methods  are  simply  different  perspectives  of  and  emphasis  on  the  same  fun¬ 
damental  activities.  In  many  ways,  we  feel  that  this  could  have  been  one  of  the  seminal  discus¬ 
sions  in  the  early  stages  of  the  Agile  movement  as  it  would  have  eased  the  misunderstandings  and 
mistrust  that  plagued  the  early  attempts  to  incorporate  Agile  principles  into  the  Traditional  water¬ 
fall  world. 

The  remainder  of  this  report  will  discuss  the  different  perspectives  that  represent  the  Agile  and 
Traditional  views  of  software  development.  As  we  will  argue,  the  what  is  the  same  (requirements, 
design,  code,  test,  integrate,  deploy),  but  the  how  can  be  quite  different.'®  To  make  it  more  con¬ 
fusing,  some  of  the  same  terms  are  used  in  both  environment  but  have  different  meanings.  Thus, 
the  context  is  important.  We  will  identify  and  define  the  more  common  terms  used  within  both 
Agile  and  Traditional,  provide  definitions,  and  provide  an  explanation  of  how  they  do — or 
don’t —  relate. 

1.2  Waterfall  Overview 

Note:  this  brief  overview  is  intended  for  the  reader  who  is  not  familiar  with  the  waterfall  software 
development  model,  and  it  is  deliberately  shorter  than  the  Agile  Overview  as  most  readers  are 
assumed  to  be  from  the  Traditional  World.  For  a  more  in-depth  discussion,  please  see  Appendix 
A. 

Before  we  begin  our  discussion  of  the  Traditional  World,  we  want  to  emphasize  that  the  people 
credited  with  the  creation  of  the  “waterfall  method”  apparently  never  envisioned  it  as  a  solution  to 
DoD’s  complex  software  development  problems.  Dr.  Winston  Royce,  the  man  who  is  often  but 
mistakenly  called  the  “father  of  waterfall”  and  the  author  of  the  seminal  1970  paper  Managing  the 
Development  of  Large  Software  Systems,  apparently  never  intended  for  the  waterfall  caricature  of 
his  model  to  be  anything  but  part  of  his  paper’s  academic  discussion  leading  to  another,  more  iter¬ 
ative  version  [Royce  1970]. 

In  his  paper  Royce  argued  for  a  more-iterative  version  of  his  “waterfall”  model,  and  went  so  far  as 
to  say  that  even  his  more-iterative  model  was  “risky  and  invites  failure.”  He  further  goes  on  to 
discuss  the  additional  steps  he  felt  were  needed  even  to  allow  even  the  more -iterative  models  to 
be  successful.  These  included  his  recommendation  that  this  model  be  run  at  least  twice  (iterative¬ 
ly),  with  the  first  time  being  a  significant  prototyping  phase  that  was  used  to  better  understand  the 
requirements,  better  understand  the  technologies  involved,  and  ensure  it  was  providing  what  the 
customers  actually  needed. 

It  is  especially  prophetic  that  Royce  stated  that  “one  could  expect  up  to  a  100-percent  overrun  in 
schedule  and/or  costs’’"  if  the  additional  steps  were  not  incorporated. 

Walker  Royce,  Royce’s  son,  said  this  of  his  father: 


But  the  reader  must  be  cautioned  we  are  not  talking  about  coding  per  se;  coding  is  still  coding  in  both  worlds 
but  there  is  a  great  difference  in  how  requirements  are  prioritized  and  managed,  work  is  planned,  testing  is  con¬ 
ceived  and  implemented,  etc. 
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“He  was  always  a  proponent  of  iterative,  incremental,  evolutionary  development.  His  paper  de¬ 
scribed  the  waterfall  as  the  simplest  description,  but  that  it  would  not  work  for  all  but  the  most 
straightforward  projects.  The  rest  of  his  paper  describes  [iterative  practices]  within  the  context  of 
the  60s/70s  government  contracting  models  (a  serious  set  of  constraints)  [Larman  2003].” 

Royce  also  emphasized  a  main  element  of  what  would  be  called  “Agile”  nearly  three  decades  later 
when  he  recommended  that  the  customer  be  involved  well  before  testing  as  “for  some  reason  what 
a  software  design  is  going  to  do  is  subject  to  wide  interpretation  even  after  previous  agreement.” 

However — and  for  a  variety  of  reasons  the  discussion  of  which  is  outside  the  scope  of  this  pa¬ 
per — Royce’s  cautions  were  not  incorporated  into  DoD  software  directives.  For  example,  DOD- 
STD-2167  (1985)  Section  4.8  Development  methodologies  states  that  “The  contractor  shall  use  a 
top-down  approach  to  design,  code,  integrate,  and  test  all  CSCIs  . . .”  Also,  the  lower  half  of  Fig¬ 
ure  1  in  DOD-STD  2167 — ^the  graphic  used  to  illustrate  software  (CSCl)  development — ^used  a 
graphic  from  the  early  part  of  Royce’s  paper — ^not  the  graphic  he  used  later  in  his  paper,  which  at 
least  indicated  iterations. 

In  its  most  basic  representation,  the  waterfall  model  has  these  main  blocks"  as  shown  in  Figure  1: 


Figure  1:  Basic  Representation  of  Waterfaii  Modei 


”  In  this  representation  we  have  added  Software  Requirements  as  the  follow-on  step  to  System  Requirements  as 
many  systems  are  not  software  only. 
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From  this  representation,  we  can  see  the  main  points  that — ^rightiy  or  wrongiy — came  to  be  the 
piiiars  of  the  Traditionai  Worid’s  waterfaii-based  software  deveiopment  approach: 

•  Systems  are  deveioped  in  a  sequential  process  (at  times  even  in  a  singie  pass). 

•  Aii  requirements  are  determined  up  front,  with  the  duai  assumptions  that  they  can  aii  be 
known  up  front,  and  that  they  are  and  wiii  remain  unchanging. 

•  Anaiysis  is  done  once,  and  precedes  design. 

•  Design  is  done  once,  and  precedes  coding. 

•  Aii  coding  is  done  once,  and  precedes  testing  and  integration. 

•  Aii  testing  is  done  once  foiiowed  by  or  in  conjunction  with  integration  activities,  and  pre¬ 
cedes  operationai  use. 

Not  inciuded  in  this  depiction  (except  by  a  generous  interpretation  of  the  arrow  iinking  each  box) 
are  these  points: 

•  Formal  review  and  approval  is  required  to  proceed  from  any  one  step  to  the  next. 

•  The  customer  is  most  involved  setting  the  requirements,  mostiy  disappears  during  anaiysis 
design,  and  coding,'^  and  re-emerges  during  test  and  acceptance. 

•  Extensive  documentation  is  required  for  each  and  every  step. 

There  were  a  number  of  reasons  why  this  approach  seemed  sound,  and  we  cannot  overstate  that 
this  approach  was  a  response  to  risk  and  uncertainty.  This  approach  was  seen  as  a  risk  manage¬ 
ment  technique,  and  was  bom  in  a  time  when  system  deveiopment  itseif  was  both  hardware- 
centric^^  and  happened  at  a  much  siower  pace  than  we  see  today. 

Some  of  the  key  risk  management  points  and  their  rationaie  that  were  incorporated  into  the  tradi¬ 
tionai,  waterfaii-based  worid  inciuded 

•  eariy  identification  of  aii  the  requirements  was  needed  to  support  pianning  and  budgeting 

•  identifying  and  iocking  down  the  requirements  eariy  in  the  program  wouid  prevent  scope 
creep 

•  documenting  aii  aspects  of  design  and  decision-making  was  needed  for  future  reference 

•  extensive  reviews  wouid  not  oniy  ensure  aii  stakehoiders  were  aware  of  progress,  but  they 
wouid  aiso  aiiow  issues  to  be  uncovered  eariier 

•  aii  requirements  needed  to  be  documented  before  any  design  work  began  to  ensure  the  archi¬ 
tecture  was  adequate 

•  aii  coding  needed  to  be  compiete  before  test  to  ensure  the  entire  system’s  capabiiities  couid 
be  evaiuated 

•  aii  requirements  had  to  be  met  before  the  system  couid  be  fieided 


The  customer  is  involved  in  design  reviews  during  these  stages,  but  these  have  generally  devolved  into  cap¬ 
stone  meetings  preceded  by  numerous  technical  interchange  meetings 

“The  main  goal  of  software  development  was  to  exploit  the  limited  hardware  resources  (storage  and  processing 
power)  in  an  optimal  way.”;  A  Synopsis  of  Software  Engineering  History:  The  Industrial  Perspective;  Albert  En- 
dres;  Position  Papers  for  Dagstuhl  Seminar  9635  on  History  of  Software  Engineering,  August  26-30,  1996 
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Taking  all  of  these  together  creates  the  framework  for  the  Traditional  World.  It  has  undergone 
many  evolutions  over  the  last  several  decades,  including  recent  efforts  to  make  it  more  “agile.” 
For  Example,  Section  804  of  the  2010  National  Defense  Authorization  Act  (NDAA)  cites  many 
principles  that  parallel  Agile  methods: 

•  early  and  continual  involvement  of  the  user; 

•  multiple,  rapidly  executed  increments  or  releases  of  capability; 

•  early,  successive  prototyping  to  support  an  evolutionary  approach;  and 

•  a  modular,  open-systems  approach. 

As  another  example.  Figure  2  is  a  depiction  of  the  process  from  a  Defense  Acquisition  University 
(DAU)  presentation  The  Defense  Acquisition  System;  note  that  the  guidance  indicates  a  program 
may  proceed  using  either  Evolutionary  Acquisition  or  Single  Step  to  Full  Capability  (i.e.,  water¬ 
fall)  [Wills  2010]. 

While  Figure  2  doesn’t  use  the  classic  waterfall  steps  as  it  moves  from  left  to  right,  it  still  main¬ 
tains  the  basic  concepts:  system  requirements  are  determined  up-front,  system  analysis  precedes 
design,  system  design  precedes  construction,  and  system  construction  precedes  deployment. 
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The  Defense  Acquisition  Management  System 


The  Materiel  Development  Decision  precedes 
entry  into  any  phase  of  the  acquisition  framework 
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Figure  2:  DAU  Representation  of  Software  Life  Cycie 
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However,  while  this  report  uses  the  waterfall  methodology  as  our  primary  framework  for  the  Tra¬ 
ditional  World,  we  don’t  mean  to  say  that  waterfall  is  the  only  software  development  paradigm 
used  by  the  Traditional  World.  For  example.  Figure  3  is  from  the  Federal  Highway  Administra¬ 
tion’s  Systems  Engineering  for  Intelligent  Transportation  Systems.'"' 

As  the  reader  can  see,  the  yellow-boxed  phases  across  the  top  effectively  match  the  phases  from 
the  DAU  document.  The  blue-boxed  system  engineering  V  also  effectively  matches  the  waterfall 
process:  development  is  still  sequential,  requirements  are  determined  up-front,  analysis  is  done 
once  and  precedes  design,  etc. 
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Figure  3:  The  System  Development  V 

It  is  true  that  most  major  development  programs  can  or  will  use  the  waterfall  or  the  system  engi¬ 
neering  V  process  many  times  as  a  system  moves  through  the  different  phases  in  the  program  life 
cycle.  It  is  also  true  that  the  V  model  also  incorporates  testing  at  each  phase  (continuous  or  near- 
continuous  test  and  integration  is  emphasized  in  Agile  methods).  However,  it  still  retains  the  same 
basic  issues  that  plague  the  waterfall  paradigm:*^ 


Adapted  from  http://ops.fhwa.dot.gov/publications/seitsguide/section6.htm 
Adapted  http://www.waterfaii-modei.com/v-modei-waterfaii-modei/ 
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•  It  assumes  that  the  requirements  and  their  order  and  priority  do  not  change. 

•  The  design  is  not  authenticated  until  later  in  the  program,  and  only  then  as  part  of  system  and 
sub-system  performance. 

•  At  each  stage  there  is  a  potential  of  errors;  the  first  testing  is  done  after  the  design  of  modules 
which  is  very  late  and  costs  a  lot. 

1.3  Agile  Overview 

Agile  is  not  one  specific  method;  Agile  is  both  a  philosophy  and  an  umbrella  term  for  a  collection 
of  methods  or  approaches  that  share  certain  common  characteristics.  One  definition  for  Agile  is 
[Lapham  2010]: 

An  iterative  and  incremental  (evolutionary)  approach  to  software  development  which  is  per¬ 
formed  in  a  highly  collaborative  manner  by  self-organizing  teams  within  an  effective  governance 
framework  with  “just  enough  ”  ceremony  that  produces  high  quality  software  in  a  cost  effective 
and  timely  manner  which  meets  the  changing  needs  of  its  stakeholders)^ 

This  definition  is  rather  long  but  it  covers  our  purposes.  If  a  shorter  definition  is  desired,  Alistair 
Cockbum  has  said  that  Agile  is  the  “. . .  early  delivery  of  business  value.  That  involves  early  and 
regular  delivery  of  working  software,  a  focus  on  team  communications,  and  close  interaction  with 
the  users.”'^ 

To  mimic  our  waterfall  characterization,  Agile  development  approaches  have  these  main  points: 

•  Requirements  are  characterized  up-front,  and  assumed  to  be  changing. 

•  Systems  evolve  during  a  series  of  short  iterations,  where  analyze,  design,  code,  test,  and  po¬ 
tentially  shippable  code  happens  each  iteration. 

•  Customer  participation  and  approval  is  required  during  each  iteration  and  to  make  the  deci¬ 
sion  to  proceed  to  the  next  iteration. 

•  Documentation  is  developed  only  as  needed  and  is  often  tailored  for  the  project. 

As  a  first  foray  into  how  Agile  is  used,  we  will  present  an  example  of  how  Agile  methods  might 
be  used  on  a  government  software  development  project.  We  must  be  very  clear — ^this  example  is 
for  discussion  only.  It  is  not  meant  to  be  all-inclusive,  it  includes  steps  or  processes  that  are  not 
used  by  all  Agile  practitioners,  and  it  incorporates  elements  of  multiple  Agile  methods.'^ 

Our  purpose  for  this  description  is  to  help  someone  not  familiar  with  Agile  methods  see  how  they 
might  be  used  in  a  government  acquisition  program.  Again — ^this  should  not  be  interpreted  as  a 
recommended  approach  but  as  an  illustration. 


http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm 

http://bradapp.blogspot.eom/2006/05/nutshell-definitions-of-agile.html 

This  is  a  nominal  representation  as  sometimes  iterations  are  collected  into  a  release  before  going  to  operations. 

Principally  Scrum  and  extreme  programming,  or  XP;  sources  include  extreme  Programming  and  SCRUM:  A 
Comparative  Analysis  of  Agile  Methods  by  Nicholas  R.  Zuiderveld  (Portland  State  University), 
http://www.scrumalliance.org/learn_about_scrum,  and  http://www.jera.com/techinfo/xpfaq.html 
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•  The  government  describes  its  needs  by  creating  a  vision  for  its  system. 

•  The  government  creates  a  list  of  relatively  coarse-grained,  high-level  requirements,  and  indi¬ 
cates  which  are  the  most  important  —  i.e.,  the  government  creates  a  prioritized  backlog  of 
product  requirements. 

•  Several  development  contractors  describe  their  proposed  approach  to  meeting  the  govern¬ 
ment’s  needs,  and  this  includes  a  high-level  cost  estimate. 

•  After  the  government  selects  one  development  contractor,  the  government  and  the  contractor 
agree  on  the  overall  scope  of  the  project — ^the  system  goals,  the  budget,  and  the  schedule. 

The  government  and  the  development  contractor  jointly  create  an  overarching,  high- 
level  plan  or  roadmap. 

Both  parties  agree  that  the  government’s  description  of  its  needs — however  thorough — 
is  incomplete  and  will  evolve  (i.e.,  requirements  and  their  priority  will  change). 

Both  parties  agree  that  the  development  contractor’s  software  development  process  — 
however  efficient — can  be  managed  but  not  fully  planned  (i.e.,  risks  happen). 

•  The  high-level  requirements  are  fleshed  out  by  putting  each  into  a  context  of  environment, 
inputs,  products,  etc.  to  make  them  easier  to  understand  and  communicate;  i.e.,  a  small  story 
is  written  about  each. 

•  The  development  contractor  refines  its  estimates  of  how  long  and  how  much  it  will  take  to 
build  the  capability  or  feature  set  needed  to  implement  a  requirement/story;  in  addition  it  as¬ 
sesses  the  risks  associated  with  each. 

•  The  product  backlog  is  then  groomed  to  balance  the  government’s  priorities  (what  the  users 
need  first)  and  the  development  contractor’s  risks  (what  risks  and  issues  must  be  explored  and 
resolved  in  order  for  system  constmction  ,  deployment,  and  operation  to  be  successful). 

•  Using  the  prioritized  product  backlog,  the  Roadmap  is  then  broken  down  into  a  series  of  re¬ 
leases. 

The  requirements  are  allocated  in  light  of  a  cross-cutting  view  of  the  overarching  high 
priority  architectural  requirements  that  must  take  place  to  achieve  the  success  of  the  iter¬ 
ations. 

The  highest  priority  requirements/stories  are  allocated  to  the  first  release  to  create  its  re¬ 
lease  backlog,  with  the  next  highest  priority  requirements  allocated  to  the  second  release 
to  create  its  release  backlog,  and  so  on. 

Each  release  in  the  roadmap  has  a  release  plan,  with  earlier  releases  having  greater  detail 
than  later  releases. 

•  The  releases  are  broken  down  into  one  or  more  iterations  (or  sprints)  which  can  range  in  du¬ 
ration  from  two  weeks  to  two  months — but  two  to  four  weeks  is  typical. 

The  iterations  are  deliberately  kept  to  short,  manageable  time  blocks  to  better  manage 
planning  and  maintain  team  focus  as  well  as  to  allow  for  frequent  product  demonstra¬ 
tions  and  team  process  improvement.^® 


™  In  a  typically  IT-oriented  project,  this  would  be  the  rate  of  consumption  of  features,  but  in  a  project  such  as  a 
safety-critical  aircraft  project  not  all  of  these  releases  are  customer-facing  but  can  be  internal  releases. 
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The  refined  cost  and  schedule  estimates  are  used  to  ensure  the  work  allocated  to  the  iter¬ 
ation  is  realistic. 

The  highest  priority  requirements/stories  from  the  release  backlog  are  allocated  to  the 
first  iteration  to  create  its  iteration  backlog,  the  next  highest  priority  requirements  are  al¬ 
located  to  the  second  iteration  to  create  its  iteration  backlog,  and  so  on. 

Each  iteration  in  a  release  has  an  iteration  plan,  with  earlier  iterations  in  the  release 
planned  in  greater  detail  and  later  iterations  planned  in  less  detail. 

•  The  iterations  are  broken  down  into  a  series  of  daily  work  assignments  (sometimes  called 
tasks)  for  the  development  team. 

•  During  each  day’s  work 

The  team  holds  a  daily  stand-up  meeting  where  each  team  member  states  what  work 
they  completed,  what  they  will  work  on  next,  and  identifies  any  issues  or  roadblocks 
they  are  facing.^' 

The  code  base  is  continuously  integrated  and  often  tested  at  least  once  a  day,^^  and  the 
code  base  must  pass  all  tests  after  integration. 

•  During  each  iteration 

The  government  (i.e.,  the  customer)  cannot  add  more  requirements  to  the  iteration,  but  it 
can  clarify  the  requirements  already  allotted  to  the  iteration. 

The  team  maintains  large,  visual  displays  of  progress  and  problems  to  keep  all  team 
members  informed;  these  displays  (sometimes  called  information  radiators)  can  be  elec¬ 
tronic  and  may  be  accessed  via  a  tool  as  opposed  to  just  displayed. 

The  release  backlog  is  groomed  and  the  plan  for  the  next  iteration  is  refined  to  allow  for 
uninterrapted  work  (i.e.,  rolling  wave  planning). 

•  At  the  end  of  each  iteration 

The  development  contractor  will  demonstrate  or  deliver  some  working,  useful  capability 
to  the  govemment.^^ 

Once  the  government  is  satisfied,  the  capability  is  prepared  for  release  or  carried  forward 
into  the  next  iteration  (depending  on  the  release  plan). 

If  appropriate,  training  materials  and  documentation  are  completed. 

If  there  are  any  unfinished  capabilities,  they  are  placed  back  in  the  backlog.  Reprioritiza¬ 
tion  may  occur  as  their  priorities  may  have  changed  and  depending  on  the  “new”  priority 
they  could  be  included  in  the  next  iteration. 

The  government  and  the  contractor  hold  a  retrospective  to  review  what  worked  and  what 
didn’t  work. 

•  At  the  end  of  each  release 

The  development  contractor  will  deliver  at  least  one  useful  capability. 


Solutions  to  the  issues  or  roadblocks  are  not  reached  during  the  stand-up.  Follow-up  meetings  or  discussions 
are  scheduled  to  accomplish  that  effort. 

Continuous  integration  and  regression  testing  is  typically  employed  at  least  daily,  and  sometimes  more  often 
depending  on  how  the  processes  are  instantiated. 

“  This  is  potentially  shippable  code.  However,  many  times  it  is  not  deployed  for  operational  reasons  or  perhaps 
because  it  provides  some  of  the  infrastructure  for  the  rest  of  the  software. 
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•  Releases  and  iterations  continue  until 

All  desired  capabilities  have  been  delivered  (the  government  can  chose  to  accept  a  less- 
than-complete  product  if  “enough”  of  the  capabilities  have  been  incorporated). 

The  money  rans  out. 

The  schedule  deadline  is  reached. 

Unlike  waterfall,  government  user  involvement  is  heavy  during  all  phases  of  the  work.  In  fact,  the 
need  for  dedicated  government  representatives  (product  owners  in  Agile  parlance)  skilled  in  Agile 
methods  is  one  of  the  biggest  challenges  that  Agile  brings  to  the  Traditional  World. 

Figure  4  shows  this  Agile  process. 
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Daily  Work 


Figure  4:  Agile  Life  Cycle 
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An  important  point  here  is  that  Agile  is  a  disciplined  planning  process,  including  understanding 
requirement  dependencies,  potential  groupings  and  infrastructure  needs.  Agile  planning  also  in¬ 
cludes  other  technical  practices  such  as  configuration  management,  testing,  and  the  like  as  part  of 
this  disciplined  planning  perspective. 
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2  Similarities — The  Same  Basic  Building  Blocks 


2.1  Similarities — Traditional  and  Agile  Share  the  Same  Goal 

What  is  sometimes  lost  in  Traditional  World/Agile  World  discussions  is  the  fact  that  both  groups 
have  the  same  goal — ^to  deliver  a  quality  product  in  a  predictable,  efficient  and  responsive  man¬ 
ner.  Both  worlds  do  the  same  “types”  of  things — define,  gather,  analyze,  design,  code,  test,  re¬ 
lease,  maintain,  retire — it’s  how  they  do  these  things  that  are  different. 

However,  we  want  to  point  out  that  while  there  are  similarities,  there  are  significant  differences. 
The  two  methods  cannot  be  thought  of  as  the  same. 

2.2  Similarities — The  Traditional  World  and  the  Agile  World  Use  Many  of  the 
Same  Principles 

As  we  showed  in  a  previous  section,  the  Traditional  World  grew  out  of  the  perception  that  the 
best  way  to  manage  the  “software  crisis”  was  to: 

•  plan  the  work  out  completely  before  beginning 

•  lock  down  requirements  early 

•  institute  multiple  reviews^"^ 

•  move  forward  in  a  step-by-step,  sequential  maimer 

•  move  forward  only  when  all  parts  of  the  previous  steps  were  complete 

•  capture  all  details  with  extensive  documentation 

Taken  individually,  it’s  difficult  to  argue  with  these  if  they  are  appropriate  (i.e.,  you  really  can 
state  all  your  requirements  up  front)  and  they  are  done  wisely.  For  example,  gold-plating  should 
be  avoided;  progress  reviews  are  reasonable  management  tools;  senior  leaders  do  need  to  be  kept 
informed  of  progress  and  issues;  designs  should  be  documented  to  support  future  work,  etc. 

Because  these  principles  have  value,  they  are  used  in  the  Agile  World  as  well;  here  is  an  example 
of  the  parallels: 


It  is  ironic  that  what  is  frequently  lost  in  the  Agile-Traditional  discussion  is  that  Agile’s  emphasis  on  frequent 
demonstrations  of  working  software  constitute  and  facilitates  the  review  process,  only  in  a  more  realistic  fash¬ 
ion. 
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Traditional  Principles 


Agile  Instantiation 


Plan  the  work — especially  the  budget, 
schedule,  and  deliverables — to  the  maxi¬ 
mum  extent  possible  before  beginning  any 
design  or  code. 


Near-term  plans  contain  more  detail,  while  plans  further  out 
on  the  time  horizon  contain  fewer  details. 

The  overall  vision  is  broken  down  into  a  roadmap,  which  is 
further  broken  down  into  release  plans,  which  are  further 
broken  down  into  sprint  or  iteration  plans,  which  are  further 
broken  down  into  daily  plans. 

Requirements  are  prioritized. 

Cost  and  schedule  estimates  are  prepared  for  each  capabil¬ 
ity  at  a  high  level.  Relative  estimation  versus  absolute  esti¬ 
mation  is  employed. 

Frequent  planning  sessions  (at  the  beginning  of  each  itera¬ 
tion)  result  in  detailed,  high-fidelity  plans. 

Risks  are  assessed  and  risk  mitigation  influences  planning. 


Lock  down  requirements  to  prevent  gold-  •  No  requirements  can  be  added  to  an  iteration  once  it  has 

plating  and  scope  creep.  started. 

•  New  requirements  are  evaluated  by  the  stakeholders  and 
prioritized  thus  preventing  gold-plating  and  scope  creep. 


Institute  multiple  reviews  to  provide  senior  •  The  customer  is  involved  in  all  aspects  of  planning  and  test- 

leadership  oversight  as  well  as  to  serve  as  ing.  Customer  (in  the  form  of  the  product  owner)  is  involved 

gates  for  continued  work.  daily. 

•  There  are  reviews  at  the  end  of  each  iteration  that  serve  as 
gates  to  further  work. 


Move  forward  in  a  step-by-step,  sequential 
manner  and  only  when  all  parts  of  the 
previous  steps  were  complete. 


The  code  base  is  integrated  and  tested  daily. 

The  code  base  must  pass  all  tests  before  and  after  integra¬ 
tion.  Regression  testing  is  typically  done  each  night. 


Capture  all  details  with  extensive  docu¬ 
mentation. 


There  is  an  overall  plan. 

There  are  requirements  descriptions. 

There  are  cost  and  schedule  estimates. 

There  are  risk  assessments. 

There  is  training  material  (as  appropriate). 

There  is  documentation  (as  appropriate). 

There  are  lessons  learned  (based  on  retrospectives). 


Table  1:  Agile  Instantiations  of  Traditional  Principles 


2.3  Similarities — The  Traditional  World  and  the  Agile  World  Use  the  Same  Basic 
Building  Blocks 

Both  the  Traditional  World  and  the  Agile  World  also  work  with  the  same  basic  programmatic 
building  blocks:^^ 


•  scope 

•  cost 

•  schedule 

•  performance 

In  its  simplest  form,  the  Traditional  World  sets  the  scope  up  front  (through  requirements)  and  then 
allows  cost,  schedule,  and  performance  to  vary.  Again  in  its  simplest  terms,  the  Agile  World  sets 
the  cost,  schedule,  and  performance  up  front  and  then  allows  the  scope  to  vary.^® 


For  simplicity,  performance  includes  all  of  the  “ilities” — quality,  interoperability,  security,  modifiability,  etc. 
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In  addition,  both  the  Traditional  World  and  the  Agile  World  use  the  same  technical  or  develop¬ 
ment  building  blocks:^^ 

•  analyze  the  requirement 

•  design  a  capability  to  satisfy  the  requirement 

•  build  the  capability 

•  test  the  capability  to  ensure  the  requirement  is  met 

•  deploy  the  capability 

In  the  Traditional  World,  the  requirements  are  fixed  and  the  five  building  blocks  move  forward  en 
masse  each  step  in  sequence  with  heavy  documentation  and  formal  approval  required,  as  shown  in 
Figure  5: 


Analyze  Design  Build  Test  Deploy 

Requirements 

Doeument 

Requirement  #1 

Requirement  #2  “ 

Requirement  #3  " 

Requirement  #4  h 

Requirement  #5  h 


Figure  5:  Requirements  Moving  En  Masse  Through  the  Process 

Sometimes  these  requirements  are  “blocked  out”  or  delivered  in  planned  increments^®  as  shown  in 
Figure  5,  but  the  effect  is  still  the  same  because  the  requirements  for  all  of  the  blocks  are  deter¬ 
mined  all  the  way  to  the  left  up  front.  Blocking  and  increments  then  are  simply  techniques  to 
manage  schedule  and  resources  but  the  sequential  paradigm  remains  (see  Figure  6). 


As  with  all  generalities,  there  is  danger  in  this  simplification.  For  example,  many  DoD  project  managers  would 
argue  that  their  schedule  is  fixed  more  than  scope  (requirements),  though  more  accurately  both  schedule  and 
requirements  are  fixed  together. 

Material  for  this  section — in  particular  the  graphics — is  adapted  from  http://www.agile-process.org/process.html 
“  Sometimes  referred  to  as  Pre-Planned  Product  Improvements,  or  P^l 
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Analyze  Design  Build  Test  Deploy 


Block  1 


Requirement 

Requirement 


Analyze  Desisn  Build  Test 


Deploy 


Block  2 


Requirement  I 

Block  3 


Analyze  Design  Build  Test  Deploy 


Requirement  I 

Figure  6:  Blocking  and  Increment  Techniques 

The  Agile  World  uses  the  same  building  blocks — it  just  looks  at  these  things  differently  than  the 
Traditional  World  as  shown  below  (Figure  7). 


Agile  Process 


High-Priority 

Requirement 


Next  High 
Priority 
Requirement 


Next  High 
Priority 
Requirement 


Next  High 
Priority 
Requirement 


Next  High 
Priority 
Requirement 


Analyze 

Design 

Build 

Test 

Deploy 


Figure  7:  Agile  Building  Blocks 
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Pure  Agilists  may  not  fully  agree  with  this  representation,  but  it  does  convey  two  key  points  in  the 
context  of  this  technical  note.  The  first  is  that  Agile  does  all  of  the  things  with  which  a  Traditional 
World  person  is  familiar — ^they  are  captured  on  the  left-hand  side.  That  leads  to  key  point  number 
one — ^Agile  methods  are  disciplined,  managed  processes. 

Key  point  number  two  is  that  what’s  “built  next”  is  always  evolving — it’s  the  highest  priority  as 
each  iteration  begins.  One  argument  against  Agile  is  that  this  flexibility  is  Agile’s  undoing  in  the 
world  of  immense  DoD  systems.  The  Traditional  World  already  struggles  with  changing  require¬ 
ments  when  requirements  are  supposedly  fixed — how  could  Agile  possibly  work  in  the  DoD  if 
customers  were  actually  encouraged  to  add  or  reprioritize  requirements? 

And  to  do  that  every  30  days'? 

There  are  several  flaws  in  this  thinking.  First,  it’s  true  that  an  undisciplined  customer  could  at¬ 
tempt  to  continuously  move  their  latest  “flavor  of  the  month”  to  the  top  of  the  backlog.  Flowever, 
for  a  requirement  to  rise  to  the  top  of  the  priority  list  it  must  be  justified  and  it  must  have  real  re¬ 
turn  on  investment  determined. 

Second,  it  is  true  that  Agile — as  with  any  development  approach — can  produce  the  wrong  system 
if  flaws  exisf  in  many  areas: 

•  the  initial  description  of  the  need  (reacting  to  symptom,  not  causes,  etc.) 

•  setting  the  initial  scope 

•  breaking  down  the  requirements 

•  initial  risk  assessments 

•  initial  cost  and  schedule  estimates 

•  and  so  forth 

Flowever,  Agile  is  geared  towards  detecting  these  flaws — it  is  designed  to  fail  early,  correct 
course,  learn,  and  improve.  As  a  simple  example,  in  an  Agile  program  working  software  is  tested 
and  integrated  daily  and  demonstrated  to  the  user  as  often  as  every  two  to  four  weeks,  which  al¬ 
lows  for  frequent  assessments  as  to  whether  the  program  is  on  track. 

In  the  Traditional  World,  building  the  wrong  system  is  more  likely  due  to  the  fact  that  the  re¬ 
quirements  are  set  years  in  advance  and  are  deliberately  resistant  to  change.  Given 

•  the  time  between  the  requirements  studies  and  the  creation  of  a  capstone  or  requirements  doc¬ 
ument 

•  the  multiple  years  to  get  into  the  federal  budget  process 

•  the  months-to-years  to  select  a  contractor 

•  the  (possibly)  multiple  years  before  a  product  is  delivered 

programs  are  often  lucky  the  requirements  were  only  half  a  decade  old. 

In  the  Traditional  World,  requirements  don’t  change.  Flowever,  the  likelihood  that  a  product  built 
to  fixed,  half-decade  old  requirements  will  still  fully  meets  the  users’  needs  and  expectations  in  an 
ever-changing  world  of  threats  and  technology  is  simply  not  realistic. 
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3  Differences — Significantly  Different  Perspectives 


3.1  Differences — Forward-Looking  Perspective  vs.  Backward-Facing  Perspective 

Perhaps  the  most  important  section  in  this  technical  note: 

•  In  a  dynamic  environment  like  the  DoD,  the  Traditional  World  straggles  to  deliver  as  it  con¬ 
stantly  looks  back  at  long-fixed  requirements  and  priorities. 

•  In  a  dynamic  environment  like  the  DoD,  the  Agile  World  adapts  as  it  delivers  by  constantly 
looking  forward  at  evolving  requirements  and  priorities. 
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4  Differences — Terms  and  Concepts 


4.1  Differences — The  Traditional  World  and  the  Agile  World  Do  Not  Use  the 
Same  Words  (Or  If  They  Do,  They  Don’t  Always  Have  the  Same  Meanings) 

It  is  a  bit  like  British  English  and  American  English,  where  sometimes  the  same  word  can  mean 
different  things.  For  example,  in  England  a  caravan  is  a  towed  trailer  that  provides  a  place  to  sleep 
when  on  a  vacation,^®  while  in  the  U.S.  a  Caravan  is  a  minivan  made  by  Chrysler,  or  a  stream  of 
cars  all  going  to  the  same  place,  as  in  “let’s  caravan  to  the  lake  this  weekend.” 

Alternatively,  the  same  item  can  be  called  by  different  names.  Consider  the  large  piece  of  sheet 
metal  covering  the  engine  bay  on  most  cars.  It’s  a  basic  component  of  every  car  in  the  world,  but 
why  do  two  people  with  presumably  the  same  language  and  presumably  the  same  goal  (e.g., 
check  the  oil)  call  it  by  such  different  terms? 

But  then  again,  sometimes  the  engine  is  in  the  back  or  the  middle,  so  “hood”  or  “bonnet”  doesn’t 
describe  what  you  want  in  either  case,  which  actually  is  a  good  segue  back  to  the  issue  at  hand. 

The  Traditional  World  and  the  Agile  World  both  use  the  same  principles  and  building  blocks — 
just  like  all  cars  have  engines — but  they  are  put  in  different  places  for  different  design  or  perfor¬ 
mance  considerations,  and  are  sometimes  accessed  via  different  routes. 

With  that  in  mind,  we’ve  selected  a  small  set  of  terms,  activities,  products,  or  roles  from  both  the 
Agile  World  and  the  Traditional  World  to  define  and  show  how  they  do — or  do  not — ^relate.  The 
number  of  terms  could  have  been  far  higher — it  seems  that  each  one  we  picked  led  us  to  two  or 
more  terms  that  needed  to  be  included.  However,  we  strove  to  keep  it  reasonably  compact,  though 
we  welcome  any  additions,  deletions,  corrections,  or  elaborations. 

NOTE:  The  definitions  were  drawn  from  many  sources.  However,  in  almost  all  cases  the  defini¬ 
tions  were  modified  or  shortened  to  better  fit  the  limitations  of  the  table.  In  those  cases  where  a 
suitable  definition  was  not  available,  we  created  one  based  on  our  overall  Agile  research. 

In  all  cases,  the  authors  encourage  readers  to  read  the  original  source  definitions  if  they  have  any 
questions  about  the  term  or  concept.  In  addition,  we  welcome  and  encourage  any  feedback 

4.1.1  Agile  World  and  Traditional  World  Terms 

We  limited  our  selection  to  25  terms  or  concepts  from  each  world.  Arguments  can  be  made  for  or 
against  including  each  term,  and  even  stronger  arguments  can  be  made  for  including  more,  but  we 
had  to  bound  this  paper.  Readers  will  also  see  that  some  terms  have  escaped  from  their  process 
context  and  have  become  general,  like  Kleenex — a  brand  name  that  has  come  to  signify  an  object 
produced  by  many  manufacturers.  These  terms  are  provided  in  that  spirit,  not  necessarily  in  the 
context  of  the  process. 


Even  “vacation”  can  lead  to  misunderstandings  as  in  England  it  would  be  called  a  “holiday”  whereas  in  the  U.S. 
a  “holiday"  generally  refers  to  a  specific  holiday  like  Christmas,  the  Fourth  of  July,  etc. 
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The  terms  and  concepts  are  listed  alphabetically,  and  are  most  easily  read  by  going  down  each 
column  rather  than  left-to-right  on  each  row.  There  is  not  an  intentional  relationship  between  Ag¬ 
ile  terms  and  Traditional  terms  that  line  up  across  from  each  other  in  the  tables;  each  term  was 
selected  based  on  its  own  significance. 


Agile  World 

Agile 

Backlog 

Burn-Down  Chart 

Complexity  Point 

Continuous  Integration 

Done 

Epic 

extreme  Programming  (XP) 

Feature 

Five  Levels  of  Agile  Planning 

INVEST 

Pair  Programming 

Planning  Poker 

Product  Owner 

Refactoring 

Release 

Retrospective 

Roadmap 

Scrum 

Sprint  (or  Iteration) 

Story  (or  User  Story) 

Story  Board 

Technical  Debt 

Velocity 

Vision 

Traditional  World 

Ball  Park  Estimate 

Bar  Chart  (or  Gantt  Chart) 

Critical  Path 

Derived  Requirements 

Earned  Value  Management 

Entry  Criteria/Exit  Criteria 

Function  Point 

Increment 

Inspection 

Integrated  Master  Plan/Integrated  Master  Schedule 

Integrated  Product  Team 

Key  Performance  Parameters 

Lightweight  Process 

Milestone  A/Milestone  B/Milestone  C 

Oversight 

Peer  Review 

Performance  Measurement  Baseline 

Preplanned  Product  Improvement  (P^l) 

PERT  (Program  Evaluation  and  Review  Technique) 

Progressive  Elaboration 

Prototype 

Requirements  Scrub 

System  Specification 

Traditional  Waterfall  Methods 

Work  Breakdown  Structure 
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Agile  Terms:  Agile 


Definitions®’^'' 

Is  there  an  equivalent  in  the  Traditional  World? 

As  we  use  the  term  in  this  technical  note, 
it  is  the  group  of  various  software  devel¬ 
opment  methodologies  that  emphasize 
most  or  all  of  these  points: 

•  requirements  evolution 

•  iterative  development 

•  continuous  test  and  integration 

•  frequent  progress  demonstra¬ 
tions 

•  frequent  delivery  of  working  code 

•  on-going,  direct  communication 
between  the  customer  and  de¬ 
veloper 

•  self-organizing,  cross-functional 
teams 

•  frequent  retrospectives  promot¬ 
ing  continuous  improvement 

As  we’ve  tried  to  show,  many  Agile  concepts  are  not  new  to  the  Tradi¬ 
tional  World  -  it’s  a  matter  of  emphasis  and  context. 

However,  perhaps  the  greatest  difference  between  the  Agile  World  and 
the  Traditional  World  is  Agile’s  explicit  acknowledgement  and  support 
for  evolving  requirements. 

How  is  it  used  in  Agile? 

Are  there  any  related  terms  or  concepts?^^ 

Fake  Agile  (Frag¬ 
ile) 

A  project  that  declares  itself  Agile  but  doesn’t  em¬ 
brace  Agile;  such  a  group  typically  dictates  its  own 
delivery  schedule  and  stops  writing  documentation 
but  doesn’t  adopt  test-driven  development  or  any 
other  practice  they  dislike. 

Hitting  the  Scrum 
Wall 

An  initial  improvement  in  productivity  and  customer 
satisfaction  after  adopting  Scrum  management 
techniques  that  comes  to  an  abrupt  end  because 
other  Agile  practices  were  not  adopted. 

ScrumBut 

When  a  project  claims  to  follow  Scrum  but  misses  or 
avoids  important  practices  as  in 

•  “We  do  Scrum  -  but  we  don’t  have  a  prod¬ 
uct  owner’’ 

•  “We  do  Scrum  -  but  the  project  manager 
allocates  tasks.” 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods:  http://www.aspe-sdlc.com 

Term  and  definition(s)  adapted  whole  or  in  part  from  http://www.accurev.com/wiki/agile-glosssary 
All  three  terms  and  definition(s)  adapted  whole  or  in  part  from  http://www.develop.com/agiledemystified 
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Agile  Terms:  Backlog 


Definition^^ 

Is  there  an  equivalent  in  the  Traditional  World? 

The  backlog  is  a  prioritized  list  of  stories 
(or  user  stories)  and  defects  ordered  from 
the  highest  priority  to  the  lowest. 

Backlogs  were  developed  in  the  context  of 
Scrum,  but  are  now  used  widely  in  many 
Agile  methods. 

Backlogs  include  both  functional  and  non¬ 
functional  stories  (or  user  stories)  as  well 
as  technical  team-generated  stories. 

There  are  three  types  of  backlogs. 

•  The  product  backlog  contains  all 
of  the  requirements  and  is  the 
highest  level. 

•  One  level  down  is  one  or  more 
release  backlog(s),  which  contain 
the  product  backlog  requirements 
as  allocated  into  releases. 

•  Two  levels  down  is  one  or  more 
sprint  (or  iteration)  backlog(s), 
which  contain  the  release  back¬ 
log  requirements  as  allocated  in¬ 
to  the  sprints. 

•  In  addition,  some  Agile  teams 
use  the  concept  of  a  daily  back¬ 
log,  which  are  composed  of  the 
sprint  or  iteration  backlog  re¬ 
quirements  as  they  are  allocated 
into  daily  work  assignments. 

This  term  is  a  frequent  source  of  confusion  as  it  has  fundamentally  dif¬ 
ferent  meanings  and  connotations. 

In  the  Traditional  World,  having  a  backlog  is  not  desirable  because  the 
backlog  is  what  the  program  expected  to  do  but  didn’t  or  couldn’t  per¬ 
form.  In  the  Traditional  World,  the  backlog  of  unfinished  or  deferred 
work  usually  falls  out  of  the  work  baseline. 

However,  it’s  true  that  in  both  worlds  not  all  work  planned  is  accom¬ 
plished.  In  Agile,  the  unfinished  work  from  a  sprint  (or  iteration)  is  re¬ 
turned  to  the  release  backlog  or  the  product  backlog  where  it  is  priori¬ 
tized  and  included  in  planning  for  future  work. 

How  is  it  used  in  Agile? 

Are  there  any  related  terms  or  concepts? 

The  concept  of  backlogs  is  a  cornerstone 
of  Agile  and  is  used  during  each  of  the  five 
levels  of  Agile  planning: 

•  Vision 

•  Roadmap 

•  Release 

•  Sprint  (or  Iteration) 

•  Daily  Work 

Backlog^'* 
{Traditional  World 
definition) 

Known  work  input  that  is  beyond  an  organization’s 
capacity  or  capability  for  any  given  period  of  time. 

Term  and  definition(s)  adapted  whole  or  in  part  from  http://www.accurev.com/wiki/agile-glosssary 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAD  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14"’  Edition,  July  201 1 
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Agile  Terms:  Burn-Down  Chart 


Definition^® 

Is  there  an  equivalent  in  the  Traditional  World? 

A  visual  tool  displaying  progress  via  a 
simple  line  chart  representing  remaining 
work  (vertical  axis)  over  time  (horizontal 
axis). 

There  isn’t  a  direct  peer  in  the  Traditional  World  for  the  Agile  burn  down 
chart.  However,  both  the  Traditional  World  and  the  Agile  World  have 
charts  with  the  same  fundamental  purpose — to  show  progress  against 
time  in  an  easily  understood  graphic. 

In  Agile,  burn-down  charts  (tracking  the  work  completed)  and  burn-up 
charts  (tracking  the  work  remaining)  in  essence  capture  the  same  type 
of  information. 

These  same  charts  also  characterize  the  information  in  another  manner 
as  the  team’s  velocity  refers  to  the  slope  of  the  line  on  the  chart  (this  is 
not  explicitly  captured  in  most  EVM  processes). 

How  is  it  used  in  Agile? 

Are  there  any  related  terms  or  concepts? 

As  a  visual  display  of  progress,  burndown 
charts  are  normally  used  at  a  release  level 
as  well  as  the  sprint  (or  Iteration)  levels. 

Burn-Up  Chart  (or 
Graph) 

A  visual  tool  displaying  progress  via  a  simple  line 
chart  representing  work  accomplished  (vertical 
axis)  over  time  (horizontal  axis). 

Burn-up  charts  are  also  normally  used  at  a  re¬ 
lease  level  as  well  as  the  sprint  (or  iteration)  lev¬ 
els. 

Agile  burn-up  charts  are  conceptually  equivalent 
to  the  Traditional  World’s  earned  value  accumu¬ 
lated  at  a  specific  date  [Cabri  2006]. 

Earned  Value  Man¬ 
agement  (EVM) 
(Traditional  World 
definition) 

A  method  combining  scope,  schedule,  and  re¬ 
source  data  into  a  measure  of  performance  and 
progress  by  comparing  what  was  budgeted  for  a 
task  (time  and  resources)  against  what  the  task 
actually  required  (time  and  resources). 

A  key  criterion  in  EVM  is  making  the  “percent 
complete”  calculations,  which  is  related  to  the 
Agile  concept  of  “done.”  It  is  also  related  to 

EVM’s  schedule  performance  index  (SPI)  and 
budgeted  cost  of  work  scheduled  (BCWS)  which 
is  also  known  as  planned  value. 

Term  and  definition(s)  adapted  whole  or  in  part  from  http://www.telerik.com/agile-project-management- 
tools/agile-resources/vocabulary.aspx 

Term  and  definition(s)  adapted  whole  or  in  part  from  http://www.telerik.com/agile-project-management- 
tools/agile-resources/vocabulary.aspx 

Terms  and  definitionjs)  adapted  whole  or  in  part  from  PMBOK  Guide®  -  Third  Edition 
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Agile  Terms:  Complexity  Point 


Definition 

Is  there  an  equivalent  in  the  Traditional  World? 

Complexity  points  are  units  of  measure 
used  to  estimate  development  work  in 
terms  of  complexity,  but  not  effort — effort 
is  measured  by  story  points. 

No  direct  peer  per  se;  however  the  Traditional  World’s  use  of  function 
points  and  function  point  anatysis  attempts  to  address  similar  issues 
(though  the  use  and  application  of  function  points  is  not  universally  or 
consistently  used). 

How  is  it  used  in  Agile? 

Are  there  any  related  terms  or  concepts? 

Complexity  Points  are  most  often  used 
during  planning  at  the  release  level  as  well 
as  the  sprint  (or  iteration)  levels. 

Story  Points®® 

According  to  Cohn,  “story  points  are  a  unit  of  meas¬ 
ure  for  expressing  the  overall  size  of  a  user  story, 
feature,  or  other  piece  of  work. .  .The  number  of  story 
points  associated  with  a  story  represents  the  overall 
size  of  the  story.  There  is  no  set  formula  for  defin¬ 
ing  the  size  of  a  story.  Rather  a  story-point  estimate 
is  an  amalgamation  of  the  amount  of  effort  involved 
in  developing  the  feature,  the  complexity  of  develop¬ 
ing  it,  the  risk  inherent  in  it  and  so  on”  [Cohn  2006]. 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods]  http://www.aspe-sdlc.com 
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Agile  Terms:  Continuous  Integration 


Definitions^ 

Is  there  an  equivalent  in  the  Traditional  World? 

Continuously  integrating  new  development 
code  into  the  existing  codebase,  which 
ensures  that  the  code  repository  always 
reflects  the  latest  working  build  of  the 
software. 

Continuous  integration  helps  identify  and 
resolve  issues  more  quickly  than  “end  of 
build”  integration. 

No  direct  peer  per  se;  however  continuous  integration  as  defined  in 

Agile  is  practiced  in  some  Traditional  World  projects. 

That  being  said,  there  is  significant  similarity  between  the  Traditional 
World  concepts  of  automated  verification  system  and  the  automated 
acceptance  test.  In  some  traditional  projects,  unit  and  integration  test 
cases  are  defined  and  built  as  part  of  the  design  phase  in  order  to  en¬ 
sure  the  developers  fully  understand  the  requirements. 

However,  in  a  strict  interpretation  the  Traditional  World’s  automated 
verification  system  isn’t  necessarily  tied  to  acceptance,  and  does  allow 
for  the  need  for  human  intervention.  Additionally,  the  Agile  automated 
acceptance  test  is  often  incorporated  into  the  daily  work. 

In  addition,  some  Agile  practices  call  for  the  automated  acceptance 
tests  to  be  built  prior  to  coding  as  a  mechanism  to  ensure  the  develop¬ 
ers  fully  understand  the  customer  requirements. 

How  is  it  used  in  Agile? 

Are  there  any  related  terms  or  concepts? 

Continuous  integration  is  most  often  used 
during  daily  work  or  at  a  sprint  (or  itera¬ 
tion)  level. 

Automated  Ac¬ 
ceptance  Tests'*® 

Tests  written  by  the  product  owner  which  are  run 
automatically  against  software  and  systems;  they 
form  part  of  the  program  specification. 

Test  Driven  Devel¬ 
opment  (TDD)'*^ 

A  technique  where  a  test  case  is  written  before 
coding  is  started  for  a  desired  improvement  or  new 
function,  code  is  written  until  it  passes  the  test,  the 
code  is  refactored  to  acceptable  standards. 

Automated  Verifi¬ 
cation  System''^ 
(Traditional  World 
definition) 

A  software  tool  that  accepts  as  input  a  computer 
program  and  a  representation  of  its  specification 
and  produces,  possibly  with  human  help,  a  proof  or 
disproof  of  the  correctness  of  the  program 

Multi-Stage 

Continuous 

Integration'*® 

Multi-stage  continuous  integration  (Cl);  each  team 
does  Cl  on  their  branch  such  that  if  a  problem  oc¬ 
curs  only  that  team  is  affected  -  not  the  entire  pro¬ 
ject. 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods:  http://www.aspe-sdlc.com 

Terms  and  definition{s)  adapted  whole  or  in  part  from  http://www.develop.com/agiledemystified 

Term  and  definition(s)  adapted  whole  or  in  part  from  http://www.telerik.com/agile-project-management- 
tools/agile-resources/vocabulary.aspx 

Terms  and  definition{s)  adapted  whole  or  in  part  from  ISA/IEC/IEEE  24765  Systems  and  Software  Engineering 
-  Vocabulary:  December  15,  2010 

Term  and  definition(s)  adapted  whole  or  in  part  from  http://www.accurev.com/wiki/agile-glosssary 
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Agile  Terms:  Done 


Definition'^'* 

Is  there  an  equivalent  in  the  Traditional  World? 

A  story  (or  user  story)  is  done  when: 

•  All  code  is  checked  in 

•  All  developer  tests  pass 

•  All  acceptance  tests  pass 

•  Help  text  is  written 

•  Product  Owner  accepted 

A  sprint  (or  Iteration)  is  done  when: 

•  Product  backup  is  complete 

•  Performance  tested 

•  Defects  fixed  or  postponed 

A  release  is  done  when: 

•  Stress  tested 

•  Performance  tuned 

•  Security  validation  passes 

•  Disaster  recovery  plan  tested 

•  Required  documentation  is  com¬ 
plete 

There  is  no  direct  peer  term  per  se  in  the  Traditional  World,  though 
there  is  the  peer  concept  of  software  being  ready  for  acceptance  testing 
or  production. 

How  is  it  used  in  Agile? 

Are  there  any  related  terms  or  concepts? 

Done  is  used  to  express  when  work  is 
complete  at  some  level,  which  can  vary. 

Done  is  often  defined  uniquely  to  a  team, 
and  care  must  be  taken  to  ensure  all 
stakeholders  share  the  same  interpreta¬ 
tion.  In  this  manner  it  is  very  similar  to 
confusion  over  the  terms  “complete”  or 
“finished”  in  the  Traditional  World,  where 
various  stakeholders  (developers,  testers, 
users,  etc.)  frequently  have  different  defi¬ 
nitions  of  the  terms. 

Done  Done 

Done  done  means  that  all  of  the  tasks  needed  to 
create  the  final,  releasable  product  have  been 
completed. 

Shrink-wrapped 
{Traditional  World 
definition) 

Software  that  is  ready  to  deliver;  i.e.,  if  it  could  be 
purchased  at  a  local  store  as  a  consumer  product  it 
would  be  wrapped  in  cellophane  or  shrink  wrap¬ 
ping. 

Acceptance  Crite- 
ria'*® 

Those  criteria  by  which  a  work  item  (user  story)  is 
judged  successful  or  not;  usually  "all  or  nothing" — it 
is  “done”  or  it  is  “not  done.” 

Acceptance  Crite¬ 
ria''® 

{Traditional  World 
definition) 

The  criteria  that  a  system  or  component  must  satis¬ 
fy  in  order  to  be  accepted  by  a  user,  customer,  or 
other  authorized  entity. 

““  Terms  and  definition{s)  adapted  whole  or  in  part  from  http://www.rallydev.com/help/definition-done 

Term  and  definition(s)  adapted  whole  or  in  part  from  http://www.accurev.com/wiki/agile-glosssary 

Terms  and  definition{s)  adapted  whole  or  in  part  from  ISA/IEC/IEEE  24765  Systems  and  Software  Engineering 
-  Vocabulary,  December  15,  2010 
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Agile  Terms:  Epic  or  Epic  Stories 


Definition 

Is  there  an  equivalent  in  the  Traditional  World? 

A  connected  or  bundled  set  of  stories  that 
result  in  a  definable  (in  the  case  of  soft¬ 
ware,  desirable)  capability  or  outcome.  An 
epic  is  a  large  user  story.  It  is  possible  to 
break  up  an  epic  into  several  user  sto- 
ries."^^ 

This  is  most  similar  to  a  system  specification  or  top-ievei  requirements 
(TLRs).  Because  Epics  can  represent  an  end-to-end  capability,  they 
are  also  similar  to  mission  threads 

How  is  it  used  in  Agile? 

Are  there  any  related  terms  or  concepts? 

Epics  are  most  often  used  during  planning 
at  the  vision  and  or  roadmap  level. 

Story  (or  User 
Story)  '•8 

Often  written  on  3”x5”  cards,  a  story  (or  user  story) 
is  a  high-level  requirement  definition  written  in  eve¬ 
ryday  or  business  language 

Product  Backlog"^® 

The  repository  of  requirements  maintained  by  the 
product  owner;  typically  high  level  requirements  with 
high  level  estimates,  and  with  the  requirements  in 
priority  order. 

Mission  Threads 
(Traditional  World 
definition) 

A  sequence  of  end-to-end  activities  and  events  be¬ 
ginning  with  an  opportunity  to  detect  a  trigger  of  an 
event  of  interest  and  ending  with  an  assessment  of 
the  effectiveness  of  any  actions  initiated  in  response 
to  the  event  of  interest. 

Term  and  definition(s)  adapted  whole  or  in  part  from 
http://www.targetprocess.com/LearnAgile/AgileGlossary/ThemeEpic.aspx 

Term  and  definition(s)  adapted  whole  or  in  part  from  http://www.telerik.com/agile-project-management- 
tools/agile-resources/vocabulary.aspx 

Term  and  definition(s)  adapted  whole  or  in  part  from  http://www.telerik.com/agile-project-management- 
tools/agile-resources/vocabulary.aspx 
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Agile  Terms:  extreme  Programming  (XP) 


Definition®** 

Is  there  an  equivalent  in  the  Traditional  World? 

XP  is  a  discipline  of  software  development 
based  on  values  of  communication,  sim¬ 
plicity,  feedback,  courage,  and  respect. 

There  is  not  a  peer  process  to  XP  in  the  Traditional  World;  in  fact  there 
are  Agile  proponents  that  feel  XP  is  the  antithesis  of  the  Traditional 
World. 

XP  consists  of  the  following  core  practic¬ 
es;  planning  poker,  on-site  customer, 
small  releases,  metaphor,  simple  design, 
test-driven  development,  refactoring,  pair 
programming,  collective  ownership,  con¬ 
tinuous  integration,  coding  standards,  and 
sustainable  pace. 

In  extreme  programming,  every  contributor  to  the  project  is  an  integral 
part  of  the  team,  and  the  team  forms  around  a  business  representative 
called  “the  customer,”  who  sits  with  the  team  and  works  with  them  dai- 
ly.5* 

How  is  it  used  in  Agile? 

Are  there  any  related  terms  or  concepts? 

XP  is  one  of  the  major  forms  of  Agile,  and 
can  be  used  during  each  of  the  five  levels 
of  Agile  planning: 

•  Vision 

•  Roadmap 

•  Release 

•  Sprint  (or  Iteration) 

Planning  Poker“ 

A  consensus-based  technique  used  to  estimate  how 
long  a  certain  amount  of  work  will  take  to  complete. 

Refactoring®^ 

Modifying/revising  code  to  improve  performance, 
efficiency,  readability,  or  simplicity  without  affecting 
functionality;  generally  considered  part  of  the  normal 
development  process  and  it  improves  longevity, 
adaptability,  and  maintainability  over  time. 

•  Daily  Work 

Pair  Program- 
ming®"* 

Two  developers  (sometimes  referred  to  as  the  “driv¬ 
er”  for  the  person  actually  coding  and  the  “observ¬ 
er”)  working  side-by-side  to  create  a  single  feature; 
it  provides  real-time  code  review,  allows  one  devel¬ 
oper  to  think  ahead  while  the  other  thinks  about  the 
work  at  hand,  and  supports  cross-training. 

The  concept  can  also  extend  to  pair  designing  and 
pair  unit  testing.  It  provides  real  time  peer  reviews. 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods]  http://www.aspe-sdlc.com  and  from  http://xprogramming.com/book/whatisxp/ 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods:  http://www.aspe-sdlc.com  and  from  http://xprogramming.com/book/whatisxp/ 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods:  http://www.aspe-sdlc.com 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods:  http://www.aspe-sdlc.com 


^  Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods:  http://www.aspe-sdlc.com 
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Agile  Terms:  Feature 


Definition®® 

Is  there  an  equivalent  in  the  Traditional  World? 

A  customer-understandable,  customer¬ 
valued  piece  of  functionality  that  serves  as 
a  building  block  for  prioritization,  planning, 
estimation,  and  reporting. 

While  the  DAU  definition  of  a  feature  is  much  simpler  (a  distinguishing 
system  characteristic),  the  underlying  meaning  is  essentially  the  same 
in  both  the  Traditional  World  and  the  Agile  World. 

How  is  it  used  in  Agile? 

Are  there  any  related  terms  or  concepts? 

The  concept  of  a  feature  is  used  during 
each  of  the  five  levels  of  Agile  planning: 

•  Vision 

•  Roadmap 

•  Release 

•  Sprint  (or  Iteration) 

•  Daily  Work 

Minimally- 

Marketable 

Feature  (MMF)  ss 

A  smallest  element  of  a  marketable  or  operationally 
useful  feature;  it  is  marketable,  or  operationally 
useful  because  when  it  is  released  as  part  of  a 
product,  users  would  use  (or  buy)  the  feature. 

Attribute®^ 
{Traditional  World 
definition) 

A  property  associated  with  a  set  of  real  or  abstract 
things  that  is  some  characteristic  of  interest. 

Feature-Based 

Planning®® 

An  approach  where  features  and  scope  take  priority 
over  date;  plans  are  created  by  estimating  the 
amount  of  time  needed  to  build  a  set  of  features  or 
a  defined  amount  of  scope. 

Feature-Driven 

Development 

(FDD)®® 

FDD  utilizes  an  incremental,  model-driven  ap¬ 
proach  based  on  five  key  activities: 

•  Define  the  overall  model 

•  Build  the  feature  list 

•  Plan  by  feature 

•  Design  by  feature 

•  Develop  by  feature 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  to  waterfall  Dictionary;  Mike  Griffiths; 
http://www.pmhut.com/agile-to-waterfall-dictionary 

Term  and  definition(s)  adapted  whole  or  in  part  from 

http://www.agilebok.org/index.  php?title=l\/linimally_Marketable_Feature_%28MMF%29 

Terms  and  definition{s)  adapted  whole  or  in  part  from  ISA/IEC/IEEE  24765  Systems  and  Software  Engineering 
-  Vocabulary,  December  15,  2010 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary;  Words  and  Terms  Common  to  Agile  Meth¬ 
ods:  http://www.aspe-sdlc.com 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods:  http://www.aspe-sdlc.com 
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Agile  Terms:  Five  Levels  of  Agile  Planning 


Definition®" 

Is  there  an  equivalent  in  the  Traditional  World? 

The  five  levels  of  Agile  planning  are: 

•  Vision  -  The  highest  level  in  agile 
planning,  the  vision  is  strategic  in 
nature  and  is  infrequently 
changed 

•  Roadmap  -  The  roadmap  distills 
the  vision  into  a  high  level  plan 
that  outlines  work  spanning  one 
or  more  releases;  requirements 
are  grouped  into  prioritized 
themes,  each  with  an  execution 
estimate. 

•  Release  -  A  release  is  a  plan¬ 
ning  segment  of  prioritized  re¬ 
quirements,  along  with  execution 
estimates 

•  Sprint  (or  Iteration)  -  An  iteration 
is  a  predefined,  time-boxed  and 
recurring  period  of  time  in  which 
working  software  is  created. 

•  Daily  Work  -  a  brief,  daily  com¬ 
munication  and  planning  forum 
where  the  development  team  and 
other  stakeholders  evaluate  the 
health  and  progress  of  the  itera¬ 
tion/sprint. 

The  Traditional  World  also  has  different  levels  of  planning  (PMBOK’s 
planning  process,  for  example)  but  does  not  structure  them  in  the  same 
framework.  Visions,  roadmaps,  and  reiease  pians  are  essentially  the 
same  as  in  the  Traditional  World;  however  their  representations  and 
scope  may  vary  from  an  Agile  approach. 

The  main  distinction  between  the  two  approaches  is  that  Agile  planning 
is  based  on  the  assumption  that  change  is  inevitable  and  must  be  ac¬ 
commodated,  while  traditional  methods  are  based  on  the  assumption 
that  deviations  from  a  plan  are  problems  that  must  be  actively  avoided. 

How  is  it  used  in  Agile? 

Are  there  any  related  terms  or  concepts? 

The  five  levels  are  used  throughout  the  life 
cycle. 

Planning  Process¬ 
es®^ 

{Traditionai  Worid 
definition) 

Those  processes  performed  to  define  and  mature 
the  project  scope,  develop  the  project  management 
plan,  and  identify  and  schedule  the  project  activities 
that  occur  within  the  project. 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods:  http://www.aspe-sdlc.com 

Terms  and  definition{s)  adapted  whole  or  in  part  from  PMBOK  Guide®  -  Third  Edition 
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Agile  Terms:  INVEST 


Definition®^ 

Is  there  an  equivalent  in  the  Traditional  World? 

From  extreme  Programing  Explored, 
INVEST  is  an  acronym  for  a  set  of  rules  to 
create  a  story  (or  user  story) 

•  Independent 

•  Negotiable 

•  Valuable 

•  Estimable 

•  Small 

•  Testable 

There  is  no  direct  peer  for  this  acronym  in  the  Traditional  World;  how¬ 
ever  in  the  Traditional  World  requirements  are  always  seen  as  needing 
to  be: 

•  Necessary 

•  Prioritized 

•  Unambiguous 

•  Verifiable 

•  Complete 

•  Consistent 

•  Traceable 

How  is  it  used  in  Agile? 

Are  there  any  related  terms  or  concepts? 

As  stated  in  the  definition,  INVEST  is  used 
during  the  planning  stages. 

The  INVEST  concept  can  be  used  during 
each  of  the  five  levels  of  Agile  planning: 

•  Vision 

•  Roadmap 

•  Release 

•  Sprint  (or  Iteration) 

•  Daily  Work 

Story  (or  user 
story)®® 

Often  written  on  3”x5”  cards,  a  story  (or  user  story) 
is  a  high-level  requirement  definition  written  in  eve¬ 
ryday  or  business  language. 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods:  http://www.aspe-sdlc.com 

Term  and  definition(s)  adapted  whole  or  in  part  from  http://www.telerik.com/agile-project-management- 
tools/agile-resources/vocabulary.aspx 
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Agile  Terms:  Pair  Programming 


Definition®^ 

Is  there  an  equivalent  in  the  Traditional  World? 

Two  developers  (sometimes  referred  to  as 
the  “driver”  for  the  person  actually  coding 
and  the  “observer”)  working  side-by-side 
to  create  a  single  feature;  it  provides  real¬ 
time  code  review,  allows  one  developer  to 
think  ahead  while  the  other  thinks  about 
the  work  at  hand,  and  supports  cross¬ 
training. 

There  is  not  a  peer  in  the  Traditional  World;  however  the  concept  of 
peer  inspections  captures  an  equivalent  quality  mechanism  to  that  of 
paired  programming. 

The  concept  can  also  extend  to  pair  de¬ 
signing  and  pair  unit  testing.  It  provides 
real  time  peer  reviews. 

How  is  it  used  in  Agile? 

Are  there  any  related  terms  or  concepts? 

Used  during  product  development  (daily 
work).  While  reviewing,  the  observer  also 
considers  the  strategic  direction  of  the 
work,  coming  up  with  ideas  for  improve¬ 
ments  and  likely  future  problems  to  ad¬ 
dress. 

This  frees  the  driver  to  focus  all  of  his/her 
attention  on  the  "tactical"  aspects  of  com¬ 
pleting  the  current  task,  using  the  observ¬ 
er  as  a  safety  net  and  guide.®® 

extreme  Pro¬ 
gramming  ®® 

XP  is  a  discipline  of  software  development  based 
on  values  of  communication,  simplicity,  feedback, 
courage,  and  respect. 

XP  consists  of  the  following  core  practices;  plan¬ 
ning  poker,  on-site  customer,  small  releases,  meta¬ 
phor,  simple  design,  test-driven  development,  re¬ 
factoring,  pair  programming,  collective  ownership, 
continuous  integration,  coding  standards,  and  sus¬ 
tainable  pace. 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods:  http://www.aspe-sdlc.com 

Term  and  definition(s)  adapted  whole  or  in  part  from  http://en.wikipedia.org/wiki/Pair_programming 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods:  http://www.aspe-sdlc.com  and  from  http://xprogramming.com/book/whatisxp/ 
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Agile  Terms:  Planning  Poker 


Definition®^ 

Is  there  an  equivalent  in  the  Traditional  World? 

A  consensus-based  estimating  technique 
using  cards  marked  with  one  number  from 
a  modified  Fibonacci  sequence  (0,1/2,  1, 

2,  3,  5,  8,  13,  20,  40,  100,  and  optionally  ? 
and  «=);  the  rules  are: 

•  The  team  selects  a  requirement 
as  the  baseline;  this  can  have 
any  value  but  is  notionally  as¬ 
signed  a  value  of  “2.” 

•  The  team  selects  a  new  require¬ 
ment,  and  team  members  dis¬ 
cuss  and  clarify  assumptions  and 
risks. 

•  Team  members  select  a  card 
whose  value  they  feel  reflects  the 
complexity  or  risk  of  the  new  re¬ 
quirement  as  compared  to  the 
baseline  (i.e.,  a  “1”  is  half  as  diffi¬ 
cult  and  a  “20”  is  an  order  of 
magnitude  more  difficult). 

•  The  team  members  reveal  their 
cards  simultaneously  by  turning 
them  over. 

•  The  people  with  the  high  and/or 
low  estimates  justify  their  selec¬ 
tion. 

•  Each  person  then  selects  a  card 
again,  and  the  process  repeats 
until  there  is  a  consensus. 

•  The  process  repeats  until  all  the 
requirements  have  been  scored. 

Similar  to  wide-band  delphi  (described  below) 

How  is  it  used  in  Agile? 

Are  there  any  related  terms  or  concepts? 

Planning  poker  is  used  during  release  and 
sprint  (or  iteration)  planning. 

Wide-Band  Del¬ 
phi®® 

{Traditional  World 
definition) 

A  group  estimation  technique  when  there  are  a 
many  unknowns;  steps  include: 

•  Describe  what  is  being  estimated. 

•  Ask  individuals  to  privately  make  their 
own  estimates  using  their  best  judgment. 

•  Present  the  estimates  and  discuss,  usu¬ 
ally  begun  by  asking  the  high/low  esti¬ 
mates  to  explain  their  thinking. 

•  Repeat  these  steps  (with  anonymity 
dropped)  until  the  estimates  converge. 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods:  http://www.aspe-sdlc.com 

Terms  and  definition{s)  adapted  whole  or  in  part  from  http://leansoftwareengineering.com/wideband-delphi 
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Agile  Terms:  Product  Owner 


Definition®®’^® 

Is  there  an  equivalent  in  the  Traditional  World? 

The  “voice  of  the  customer,”  accountable 
for  ensuring  business  value  is  delivered  by 
creating  customer-centric  items  (typically 
stories  (or  user  stories),  prioritizing  them, 
and  maintaining  them  in  the  product  back¬ 
log. 

In  scrum,  the  product  owner  is  the  sole 
person  responsible  for  managing  the 
product  backlog;  they: 

•  Define  the  product  backlog  items 

•  Prioritize  the  product  backlog  to 
reflect  goals  and  missions 

•  Keep  the  product  backlog  visible 
to  all 

•  Define  the  sprint  backlog  items 

•  Ensure  the  developers  fully  un¬ 
derstand  the  backlog  items 

However,  the  product  owner  does  not 
specifically  have  to  be  one  person;  this 
role  could  be  carried  out  by  one  person  or 
a  group  could  own  it.  The  main  point  is 
that  that  there  is  “one  voice”  for  the  cus¬ 
tomer. 

Similar  in  concept  to  the  Traditional  World’s  voice  of  the  customer,  but 
with  the  significant  difference  that  in  agile  the  product  owner  is  much 
more  involved  in  the  software  development  daily  operations  as  well  as 
release  and  sprint  planning,  prioritization,  etc.  and  thus  has  more  influ¬ 
ence  on  the  developer’s  decisions  making  process. 

In  the  Traditional  World,  the  actual  implementation  of  the  product  owner 
role  is  shared  among  many  different  stakeholders  such  as  the  end  user, 
systems  engineer,  product  architect,  solution  analysis,  program  manag¬ 
er,  etc. 

In  theory,  sharing  this  role  among  so  many  stakeholders  should  ensure 
that  at  least  one  of  the  product  owner(s)  is  always  available  to  support 
the  software  development  activities.  However,  that  is  frequently  not  the 
case  because  the  role  is  not  explicit. 

Also,  with  the  role  split  among  many  different  stakeholders  there  are 
sometimes  conflicting  perspectives  which  can  hamper  or  delay  activi¬ 
ties. 

How  is  it  used  in  Agile? 

Are  there  any  related  terms  or  concepts? 

The  product  owner  is  involved  in  all  stages 
of  an  Agile  project. 

In  fact  the  demands  placed  on  the  product 
owner  (time  commitment,  knowledge  of 
the  domain,  and  knowledge  of  Agile  de¬ 
velopment  methods)  are  one  of  the  key 
stumbling  blocks  in  the  Traditional  World’s 
Agile  adoption. 

Voice  of  the 
Customer 
{Traditional  World 
definition) 

A  survey  technique  to  capture  a  detailed  set  of 
customer  needs  and  desires  using  the  customer’s 
language,  translating  these  into  technical  re¬ 
quirements,  and  putting  them  in  priority  order. 

HOWEVER — the  Traditional  voice  of  the  custom¬ 
er  is  a  survey  technique,  where  the  Agile  product 
owner  is  an  active  role  and  responsibility. 

Term  and  definition(s)  adapted  whole  or  in  part  from  http://www.telerik.com/agile-project-management- 
tools/agile-resources/vocabulary.aspx 

Terms  and  definition{s)  adapted  whole  or  in  part  from  The  Scrum  Guide  -  The  Definitive  Guide  to  Scrum:  Rules 
of  the  Game;  Schwaber  and  Sutherland,  scruminc 
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Agile  Terms:  Refactoring 


Definitions^ 

Is  there  an  equivalent  in  the  Traditional  World? 

Modifying/revising  code  in  to  improve  per¬ 
formance,  efficiency,  readability,  or  sim¬ 
plicity  without  affecting  functionality;  gen¬ 
erally  considered  part  of  the  normal 
development  process  and  it  improves  lon¬ 
gevity,  adaptability,  and  maintainability 
over  time. 

There  is  not  a  direct  peer  for  this  in  the  Traditional  World,  although  re¬ 
factoring  can  be  argued  to  be  a  general  software  development  ap¬ 
proach  that  has  simply  been  most  popularized  by  Agile. 

There  are  also  similarities  with  elements  of  the  Traditional  World’s  soft¬ 
ware  redesign  or  reengineering.  These  processes  result  in  the  design 
and  implementation  of  a  new  overall  structure  without  changing  its  ex¬ 
ternal  behavior,  and  share  the  refactoring  goal  of  correcting  deficiencies 
in  the  software  design  and  supporting  future  enhancements. 

However,  redesign  and  reengineering  can  also  include  adopting  a  new 
programming  paradigm  (such  as  a  transition  from  unstructured  to  struc¬ 
tured  programming  or  to  object-oriented  programming),  which  is  well 
beyond  the  normal  use  of  Agile  refactoring. 

How  is  it  used  in  Agile? 

Are  there  any  related  terms  or  concepts? 

Refactoring  was  popularized  as  a  practice 
in  extreme  programming,  but  was  used 
prior  to  XP  and  is  now  used  by  most  Agile 
methods  as  a  normal  part  of  the  develop¬ 
ment  process 

extreme  Pro¬ 
gramming 

XP  is  a  discipline  of  software  development  based 
on  values  of  communication,  simplicity,  feedback, 
courage,  and  respect. 

XP  consists  of  the  following  core  practices:  plan¬ 
ning  poker,  on-site  customer,  small  releases,  meta¬ 
phor,  simple  design,  test-driven  development,  re¬ 
factoring,  pair  programming,  collective  ownership, 
continuous  integration,  coding  standards,  and  sus¬ 
tainable  pace. 

Simple  Design’^® 

To  paraphrase  the  poet  Wallace  Stevens,  simple 
design  is  "the  art  of  what  suffices." 

Simple  design  means  coding  for  today's  specified 
requirements,  and  no  more. 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods:  http://www.aspe-sdlc.com 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods:  http://www.aspe-sdlc.com  and  from  http://xprogramming.com/book/whatisxp/ 

Term  and  definition(s)  adapted  whole  or  in  part  http://www.versionone.com/Agile101/Simple_Design.asp 
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Agile  Terms:  Release 


Definition^^ 

Is  there  an  equivalent  in  the  Traditional  World? 

The  third  of  the  five  levels  of  Agile  plan¬ 
ning: 

•  Vision  -  The  highest  level  in  agile 
planning,  the  vision  is  strategic  in 
nature  and  is  infrequently 
changed. 

•  Roadmap  -  The  roadmap  distills 
the  vision  into  a  high  level  plan 
that  outlines  work  spanning  one 
or  more  releases;  requirements 
are  grouped  into  prioritized 
themes,  each  with  an  execution 
estimate. 

•  Release  -  A  release  is  a  plan¬ 
ning  segment  of  prioritized  re¬ 
quirements,  along  with  execution 
estimates. 

•  Sprint  (or  iteration)  -  An  iteration 
is  a  predefined,  time-boxed  and 
recurring  period  of  time  in  which 
working  software  is  created. 

•  Daily  Work  -  a  brief,  daily  com¬ 
munication  and  planning  forum 
where  the  development  team  and 
other  stakeholders  evaluate  the 
health  and  progress  of  the  itera¬ 
tion/sprint. 

This  is  another  term  which  can  cause  confusion.  In  Agile,  a  release  is 
part  of  the  planning  process.  However,  at  the  end  of  each  release  the 
development  contractor  will  deliver  some  element  of  a  militarily  useful 
capability  to  the  government.  (This  does  not  mean  that  the  capability  is 
fielded  at  this  point,  but  it  does  mean  that  it  could  be  fielded.) 

What  this  means  is  that  a  release  in  Agile  often  does  result  in  a  deliver¬ 
able — ^which  in  the  Traditional  World  is  often  called  a  “release”  (see  the 
definition  below). 

How  is  it  used  in  Agile? 

Are  there  any  related  terms  or  concepts? 

Planning 

Release'’® 
{Traditional  World 
definition) 

A  delivered  version  of  an  application  which  may 
include  all  or  part  of  an  application. 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods:  http://www.aspe-sdlc.com 

Terms  and  definition{s)  adapted  whole  or  in  part  from  ISA/IEC/IEEE  24765  Systems  and  Software  Engineering 
-  Vocabulary:  December  15,  2010 
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Agile  Terms:  Retrospect 

ive 

Definition^® 

Is  there  an  equivalent  in  the  Traditional  World? 

A  team  meeting  at  the  end  of  every  itera¬ 
tion  to  review  lessons  learned  and  to  dis¬ 
cuss  how  the  team  can  be  more  efficient 
in  the  future. 

The  closest  peer  in  the  Traditional  World  is  a  hot  wash  (see  below),  but 
in  Agile  retrospectives  are  much  more  integrated  into  the  project’s 
rhythm. 

The  Traditional  World  also  performs  project  post-mortems  which  share 
many  of  the  same  goals  but  are  usually  only  performed  once  at  the  end 
of  a  project  so  the  lessons  learned  can  only  improve  future  projects. 
Retrospectives,  on  the  other  hand,  are  designed  to  improve  the  current 
project  as  well  as  future  projects. 

How  is  it  used  in  Agile? 

Are  there  any  related  terms  or  concepts? 

The  retrospective  is  an  integral  part  of 
Agile  planning  and  process/product  im¬ 
provement;  the  most  common  examples 
are  sprint  (or  iteration)  retrospectives,  and 
release  retrospectives. 

Hot  Wash^^ 
{Traditional  World 
definition) 

Discussions  and  performance  evaluations  follow¬ 
ing  an  exercise,  training  session,  or  event  to  iden¬ 
tify  strengths,  weaknesses  and  lessons  learned; 
normally  includes  all  the  parties  that  participated 
in  the  exercise  or  event. 

Terms  and  definition{s)  adapted  whole  or  in  part  from  PMBOK  Guide'^  -  Third  Edition 
Terms  and  definition{s)  adapted  whole  or  in  part  from  http://www.develop.com/agiledemystified 
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Agile  Terms:  Roadmap 


Definition^® 

Is  there  an  equivalent  in  the  Traditional  World? 

The  second  of  the  five  levels  of  Agile 
planning: 

•  Vision  -  The  highest  level  in  agile 
planning,  the  vision  is  strategic  in 
nature  and  is  infrequently 
changed. 

•  Roadmap  -  The  roadmap  distills 
the  vision  into  a  high  level  plan 
that  outlines  work  spanning  one 
or  more  releases;  requirements 
are  grouped  into  prioritized 
themes,  each  with  an  execution 
estimate. 

•  Release  -  A  release  is  a  plan¬ 
ning  segment  of  prioritized  re¬ 
quirements,  along  with  execution 
estimates. 

•  Sprint  (or  iteration)  -  An  iteration 
is  a  predefined,  time-boxed  and 
recurring  period  of  time  in  which 
working  software  is  created. 

•  Daily  Work  -  a  brief,  daily  com¬ 
munication  and  planning  forum 
where  the  development  team  and 
other  stakeholders  evaluate  the 
health  and  progress  of  the  itera¬ 
tion/sprint. 

While  elements  of  the  roadmap  could  also  comprise  parts  of  the  Tradi¬ 
tional  World’s  project  charter,  it  is  most  like  the  Traditional  World’s  ac¬ 
quisition  program  baseiine  (see  below). 

It  is  also  similar  to  the  Traditional  World’s  integrated  master pian  (IMP) 
or  master  phasing  scheduie. 

How  is  it  used  in  Agile? 

Are  there  any  related  terms  or  concepts? 

Planning 

Acquisition  Pro¬ 
gram  Base¬ 

line  (APB)  79 
{Traditionai  Worid 
definition) 

Baseline  reflecting  threshold  and  objective  values 
for  the  cost,  schedule,  and  performance  attributes 
that  describe  the  program  over  its  life  cycle: 

•  Life  cycle  cost  estimate  (LCCE) 

•  Schedule  dates  including  key  activities 
such  as  milestones  and  the  initial  opera¬ 
tional  capability  (IOC) 

•  Performance  attributes  reflecting  the  op¬ 
erational  performance  required  for  the 
fielded  system 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods:  http://www.aspe-sdlc.com 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14“’  Edition,  July  201 1 
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Agile  Terms:  Scrum 


Definition®** 

Is  there  an  equivalent  in  the  Traditional  World? 

A  process  framework  of  team  members 
and  their  associated  roles  (product  own¬ 
ers,  Scrum  masters  and  team  members 
such  as  developers,  testers,  etc.)  who 
collaboratively  define  product  and  sprint 
backlogs  that  are  executed  in  short,  time- 
boxed  sprints  (or  iterations). 

At  the  end  of  each  sprint,  a  working  in¬ 
crement  of  the  software  is  delivered  or 
demonstrated  to  the  product  owner,  and 
the  entire  process  repeats  itself. 

There  isn’t  a  direct  peer  in  the  Traditional  World.  There  are  many  ex¬ 
amples  in  the  Traditional  World  that  contain  the  iterative  and  incremen¬ 
tal  aspects  of  Scrum  (particularly  spiral  development  or  the  IBM  Ration¬ 
al  Unified  Process®  or  RUP  ®),  but  they  lack  key  elements  of  a  Scrum: 

•  Daily  close  collaboration  on  a  working  level 

•  Short  iterations 

•  Planning  cycles  are  done  at  the  start  of  each  new  body  of  work 
vs.  all  planning  done  up  front  before  any  body  of  work  begins 

Some  elements  of  Scrum  are  also  in  the  Traditional  World  such  as  de¬ 
sign  reviews  and  technical  interchange  meetings  (TIMs),  but  these  are 
usually  on  a  “grander  scale”  than  Scrum  demonstrations. 

How  is  it  used  in  Agile? 

Are  there  any  related  terms  or  concepts? 

Management,  planning 

Scrum  Master®* 

The  Scrum  master  is  not  the  development  team 
leader  per  se  -  they  buffer  the  team  from  distracting 
influences  while  they  ensure  the  Scrum  process  is 
used  as  intended.  The  Scrum  master  also  removes 
roadblocks,  handles  the  paperwork,  and  generates 
the  burn-down  chart  (metrics). 

Scrum  of 

Scrums®^ 

(only  used  on 
larger  teams) 

A  daily  meeting  that  occurs  after  individual  team’s 
daily  stand  up,  it  allows  multiple  Scrum  teams  to 
stay  synchronized  and  understand  the  flow  and 
challenges  of  the  other  teams. 

Each  Scrum  master  addresses  these  questions: 

•  What  did  my  team  complete? 

•  What  is  my  team  working  on  next? 

•  What  barriers/issues  are  my  team  facing? 

ScrumBut®® 

A  project  that  claims  to  follow  Scrum  but  doesn’t: 

•  “We  do  Scrum — but  we  don’t  have  a  prod¬ 
uct  owner” 

•  “We  do  Scrum — but  the  project  manager 
allocates  tasks.” 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods:  http://www.aspe-sdlc.com 

Term  and  definition(s)  adapted  whole  or  in  part  from  http://www.telerik.com/agile-project-management- 
tools/agile-resources/vocabulary.aspx 

Term  and  definition(s)  adapted  whole  or  in  part  from  http://www.telerik.com/agile-project-management- 
tools/agile-resources/vocabulary.aspx 

Terms  and  definition{s)  adapted  whole  or  in  part  from  http://www.develop.com/agiledemystified 
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Agile  Terms:  Sprint  (or  11 

teration) 

Definition®^ 

Is  there  an  equivalent  in  the  Traditional  World? 

A  predefined,  time-boxed,  and  recurring 
block  of  time  in  which  working  software  is 
created —  most  commonly  two,  four,  or  six 
weeks  long. 

“Sprint”  and  “iteration”  are  effectively  in¬ 
terchangeable,  with  sprint  used  by  teams 
implementing  Scrum. 

Activity  or  work  package  (see  below)  may  be  the  closest  peer  in  the 
Traditional  World  as  the  concept  of  a  basic  schedule  building  block  is 
used  in  both  Agile  and  the  Traditional  World. 

However,  the  principal  difference  is  that  in  Agile,  the  planning  is  taken 
“to  the  edge” — it  is  done  by  the  people  most  affected  by  the  planning, 
who  are  best  suited  to  make  realistic  choices,  and  who  have  a  vested 
interest  in  ensuring  the  work  can  be  accomplished. 

How  is  it  used  in  Agile? 

Are  there  any  related  terms  or  concepts? 

Sprints  (or  iterations)  are  more  than  just 
the  basic  building  blocks  of  Agile  schedul¬ 
ing  and  product  development;  they  repre¬ 
sent  a  deliberate  approach  to  planning 
and  executing  work  in  manageable 
“chunks”  with  known  goals,  known  re- 
sources,  and  with  the  scope  adjusted  to  fit 
the  known  schedule. 

Sprint  (or  Itera¬ 
tion)  Backlog®® 

The  subset  of  stories  (or  user  stories)  and/or  fea¬ 
tures  from  the  product  backlog  planned  to  be 
completed  in  a  specific  sprint  (or  iteration).  It  re¬ 
flects  the  priority  and  order  of  the  release  plan 
and  product  roadmap. 

Sprint  (or  Itera¬ 
tion)  Plan®® 

The  detailed  execution  plan  for  a  given  (usually 
current)  sprint  (or  Iteration);  it  defines  the  iteration 
goals  and  commitments  by  specifying  the  user 
stories,  work  tasks,  priorities  and  team  member 
work  assignments  required  to  complete  the  itera¬ 
tion.  The  sprint  plan  is  normally  produced  by  the 
entire  development 

Work  Package®^ 
{Traditionai  Worid 
definition) 

A  work  package  is  a  deliverable  or  component  at 
the  lowest  level  of  the  work  breakdown  structure; 
it  is  a  task,  activity  or  grouping  of  work  at  the  low¬ 
est  level  where  work  is  planned,  progress  is 
measured,  and  earned  value  is  computed. 

Activity®® 

{Traditionai  Worid 
definition) 

A  task  or  measurable  amount  of  work  to  complete 
a  job  or  part  of  a  project. 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  to  Waterfall  Dictionary;  Mike  Griffiths; 
http://www.pmhut.com/agile-to-waterfall-dictionary 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods;  http://www.aspe-sdlc.com 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods;  http://www.aspe-sdlc.com 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14*’’  Edition,  July  201 1 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14“’  Edition,  July  201 1 
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Agile  Terms:  Story  (or  User  Story) 


Definition®® 

Is  there  an  equivalent  in  the  Traditional  World? 

Often  written  on  3”x  5”  cards,  a  story  (or 
user  story)  is  a  high-level  requirement 
definition  written  in  everyday  or  business 
language;  it  is  a  communication  tool  writ¬ 
ten  by  or  for  the  customers  to  guide  de¬ 
velopers  though  it  can  also  be  written  by 
developers  to  express  non-functional  re¬ 
quirements  (security,  performance,  quali¬ 
ty,  etc.). 

Stories  (or  user  stories)  are  not  vehicles  to 
capture  complex  system  requirements  on 
their  own.  Rather,  full  system  require¬ 
ments  consist  of  the  body  of  stories  (or 
user  stories). 

An  epic  is  a  large  story  (or  user  story)  that 
will  eventually  be  broken  down  into  small¬ 
er  stories  (or  user  stories)  that  will  be  cap¬ 
tured  in  the  product  backlog. 

Stories  (or  user  stories)  are  most  similar  to  requirements  in  the  Tradi¬ 
tional  World. 

Stories  (or  user  stories)  in  Agile  describe  the  same  thing  as  require¬ 
ments  in  the  Traditional  World — they  capture  what  the  system  must  do. 

When  combined  together  in  the  Agile  product  backlog,  the  stories  (or 
user  stories)  form  a  comprehensive  set  of  what  the  system  “must  do.” 

How  is  it  used  in  Agile? 

Are  there  any  related  terms  or  concepts? 

Stories  (or  User  Stories)  are  used  in  all 
levels  of  Agile  planning  and  execution: 

•  Vision 

•  Roadmap 

•  Release 

•  Sprint  (or  Iteration) 

•  Daily  Work 

Requirement®® 
{Traditional  World 
definition) 

A  condition  or  capability  needed  by  a  user  to 
solve  a  problem  or  achieve  an  objective. 

Story  Points®'' 

According  to  Cohn,  “story  points  are  a  unit  of 
measure  for  expressing  the  overall  size  of  a  user 
story,  feature,  or  other  piece  of  work... The  num¬ 
ber  of  story  points  associated  with  a  story  repre¬ 
sents  the  overall  size  of  the  story.  There  is  no  set 
formula  for  defining  the  size  of  a  story.  Rather  a 
story-point  estimate  is  an  amalgamation  of  the 
amount  of  effort  involved  in  developing  the  fea¬ 
ture,  the  complexity  of  developing  it,  the  risk  in¬ 
herent  in  it  and  so  on”  [Cohn  2006]. 

Term  and  definition(s)  adapted  whole  or  in  part  from  http://www.telerik.com/agile-project-management- 
tools/agile-resources/vocabulary.aspx 

Terms  and  definition{s)  adapted  whole  or  in  part  from  ISA/IEC/IEEE  24765  Systems  and  Software  Engineering 
-  Vocabulary-,  December  15,  2010 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods]  http://www.aspe-sdlc.com 
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Agile  Terms:  Story  Board 


Definition 

Is  there  an  equivalent  in  the  Traditional  World? 

A  wall  chart  (or  digital  equivalent)  with 
markers  (cards,  sticky  notes,  etc.)  for  each 
task  in  a  sprint  or  iteration;  the  board  is 
divided  into  “to  do”,  “in  progress”,  “done”, 
etc.  and  the  movement  of  the  markers 
across  the  board  indicates  progress. 

One  goal  of  the  story  board  is  also  to  rec¬ 
ognize  the  order  and  the  dependencies  of 
the  stories  in  representing  end-to-end 
functionality  for  the  users. 

Similar  to  story  maps®^,  which  are  a  visual 
technique  to  prioritize  stories  (or  user  sto¬ 
ries)  by  creating  a  “map”  of  users,  their 
activities,  and  the  stories  (or  user  stories) 
needed  to  implement  the  functionality 
needed 

There  are  several  similar  concepts  in  the  Traditional  World.  For  exam¬ 
ple,  some  Traditional  World  war  rooms  have  had  the  same  goal  as  an 
Agile  story  board. 

The  Traditional  World’s  project  management  dashboard  is  also  similar 
in  concept  as  it  is  a  simple-to-read  graphical  presentation  of  the  current 
status  and  in  some  cases  historical  trends  of  performance;  one  promi¬ 
nent  example  is  the  federal  government’s  IT  dashboard 
(http://www.itdashboard.gov/). 

Also,  the  IMS  {integrated  master  schedule)  allows  for  teams  to  identify 
tasks  that  have  not  started  (to  do),  in  progress  (in  progress),  and  com¬ 
pleted  (done).  However,  the  story  board  is  usually  much  more  detail 
than  what  is  in  an  IMS. 

How  is  it  used  in  Agile? 

Are  there  any  related  terms  or  concepts? 

A  Story  Board  could  be  used  in  all  levels 
of  Agile  planning  and  execution: 

•  Vision 

•  Roadmap 

•  Release 

•  Sprint  (or  Iteration) 

•  Daily  Work 

Story  Maps®® 

A  visual  technique  to  prioritize  stories  (or  user 
stories)  by  creating  a  “map”  of  users,  their  activi¬ 
ties,  and  the  stories  (or  user  stories)  needed  to 
implement  the  functionality  needed. 

War  Room®"^ 
{Traditional  World 
definition) 

A  room  used  for  project  conferences  and  plan¬ 
ning,  often  displaying  charts  of  cost,  schedule 
status,  and  other  key  project  data. 

Information 

Radiator®® 

(Or  Task  Board) 

A  display  posted  in  a  public  place  showing  read¬ 
ers  relevant  information;  it  should  be: 

•  easily  visible  to  casual  but  interested 
readers 

•  able  to  be  understood  at  a  glance 

•  kept  current 

Term  and  definition(s)  adapted  whole  or  in  part  from  http://www.agilelearninglabs.com/modules/story-mapping/ 

Term  and  definition(s)  adapted  whole  or  in  part  from  http://www.agilelearninglabs.com/modules/story-mapping/ 

Terms  and  definition{s)  adapted  whole  or  in  part  from  ISA/IEC/IEEE  24765  Systems  and  Software  Engineering 
-  Vocabulary,  December  15,  2010 

Term  and  definition(s)  adapted  whole  or  in  part  from  http://alistair.cockburn.us/lnformation+radiator 
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Agile  Terms:  Technical  Debt 


Definition®® 

Is  there  an  equivalent  in  the  Traditional  World? 

Technical  debt  includes  those  internal 
things  (such  as  architectural  elements, 
strategic  development  tasks  such  as 
common  methods,  etc.)  that  you  choose 
not  to  do  now,  but  which  will  impede  future 
development  if  left  undone.  This  includes 
deferred  refactoring. 

Technical  debt  doesn't  include  deferred 
functionality,  except  possibly  in  edge  cas¬ 
es  where  delivered  functionality  is  "good 
enough"  for  the  customer,  but  doesn't 
satisfy  some  standard  (e.g.,  a  Ul  element 
that  isn't  fully  compliant  with  some  Ul 
standard) 

As  we  write  this  in  2012,  technical  debt  is  principally  used  in  Agile,  and 
is  not  frequently  used  in  the  Traditional  World. 

However,  the  concept  has  been  understood  in  the  Traditional  World  for 
many  years.  In  1980  Manny  Lehman  wrote  The  Law  of  Increasing 
Complexity  [Lehman  1980]: 

"As  an  evolving  program  is  continually  changed,  its  complexity,  reflect¬ 
ing  deteriorating  structure,  increases  unless  work  is  done  to  maintain  or 
reduce  it." 

The  technical  debt  metaphor  was  coined  by  Ward  Cunningham  in  a 

1992  Object-Oriented  Programming,  Systems,  Languages  and  Applica¬ 
tions  (OOPSLA)  experience  report:®^ 

“Shipping  first  time  code  is  like  going  into  debt.  A  little  debt  speeds  de¬ 
velopment  so  long  as  it  is  paid  back  promptly  with  a  rewrite...  The  dan¬ 
ger  occurs  when  the  debt  is  not  repaid.  Every  minute  spent  on  not- 
quite-right  code  counts  as  interest  on  that  debt.  Entire  engineering  or¬ 
ganizations  can  be  brought  to  a  standstill  under  the  debt  load  of  an  un¬ 
consolidated  implementation,  object-oriented  or  otherwise.  ” 

How  is  it  used  in  Agile? 

Are  there  any  related  terms  or  concepts? 

The  concept  of  technical  debt  is  most  ap¬ 
plicable  to  Agile  planning  and  execution  at 
the  release  and  sprint  (or  iteration)  level. 

Refactoring®® 

Modifying/revising  code  in  to  improve  performance, 
efficiency,  readability,  or  simplicity  without  affecting 
functionality;  generally  considered  part  of  the  nor¬ 
mal  development  process  and  it  improves  longevity, 
adaptability,  and  maintainability  over  time. 

Terms  and  definition{s)  adapted  whole  or  in  part  from  http://c2.com/cgi/wiki7TechnicalDebt 
http://c2.com/doc/oopsla92.html 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods]  http://www.aspe-sdlc.com 
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Agile  Terms:  Velocity 


Definition®® 

Is  there  an  equivalent  in  the  Traditional  World? 

The  rate  at  which  work  is  completed,  nor¬ 
mally  measured  by  the  number  of  story 
points  completed  within  an  iteration;  it  is  a 
predictive  metric  used  for  planning. 

This  term  is  not  used  in  the  Traditional  World,  though  the  concept  of 
“how  much  work  will  be  accomplished  in  how  much  time”  is  fundamental 
in  the  Traditional  World  as  it  is  in  Agile.  In  both  worlds,  classes  of  work 
are  defined,  measures  to  the  effort  needed  to  complete  that  work  are 
derived,  and  how  much  work  was  accomplished  is  measured. 

There  are  similarities  between  velocity  and  aspects  of  the  Traditional 
World’s  earned  value  system,  but  as  with  all  discussions  of  software 
productivity  there  are  many  issues  regarding  what  to  measure,  how  to 
measure,  who  should  measure,  etc.  Velocity  also  uses  story  points 
which  have  an  inherent  level  of  uncertainty. 

Velocity  also  has  similarities  with  the  Traditional  World’s  schedule  per¬ 
formance  index  (SPI),  which  is  a  historical  measure  of  how  much  work 
the  team  expected  to  complete  and  how  much  work  was  actually  com¬ 
pleted.  However,  velocity  is  not  “guessed”  ahead  of  time,  but  is  refined 
as  sprints  are  completed  and  becomes  a  predictor. 

How  is  it  used  in  Agile? 

Are  there  any  related  terms  or  concepts? 

Velocity  is  most  applicable  to  Agile  plan¬ 
ning  and  execution  at  the  release,  sprint 
(or  iteration),  and  daily  work  level. 

Cadence 

Cadence  is  an  efficient  and  sustainable  working 
rhythm,  incorporating  elements  such  as  the  daily 
work  and  stand-up  meetings,  weekly  planning  ses¬ 
sions  and  reviews,  regular  demonstrations  and  ret¬ 
rospectives,  etc. 

Sustainable 

Pace^“ 

Agile  processes  promote  sustainable  development. 
The  sponsors,  developers,  and  users  should  be 
able  to  maintain  a  constant  pace  indefinitely. 

Story  Points''®'' 

According  to  Cohn,  “story  points  are  a  unit  of 
measure  for  expressing  the  overall  size  of  a  user 
story,  feature,  or  other  piece  of  work... The  number 
of  story  points  associated  with  a  story  represents 
the  overall  size  of  the  story.  There  is  no  set  formula 
for  defining  the  size  of  a  story.  Rather  a  story-point 
estimate  is  an  amalgamation  of  the  amount  of  effort 
involved  in  developing  the  feature,  the  complexity  of 
developing  it,  the  risk  inherent  in  it  and  so  on” 

[Cohn  2006]. 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods:  http://www.aspe-sdlc.com 

For  the  principles  behind  the  Agile  Manifesto,  see  http://agilemanifesto.org/principles.html 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods:  http://www.aspe-sdlc.com 
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Agile  Terms:  Vision 


Definition^®^ 

Is  there  an  equivalent  in  the  Traditional  World? 

The  first  of  the  five  levels  of  Agile  plan¬ 
ning: 

•  Vision  -  The  highest  level  in  agile 
planning,  the  vision  is  strategic  in 
nature  and  is  infrequently 
changed 

•  Roadmap  -  The  roadmap  distills 
the  vision  into  a  high  level  plan 
that  outlines  work  spanning  one 
or  more  releases;  requirements 
are  grouped  into  prioritized 
themes,  each  with  an  execution 
estimate. 

•  Release  -  A  release  is  a  plan¬ 
ning  segment  of  prioritized  re¬ 
quirements,  along  with  execution 
estimates 

•  Sprint  (or  Iteration)  -  An  iteration 
is  a  predefined,  time-boxed  and 
recurring  period  of  time  in  which 
working  software  is  created. 

•  Daily  Work  -  a  brief,  daily  com¬ 
munication  and  planning  forum 
where  the  development  team  and 
other  stakeholders  evaluate  the 
health  and  progress  of  the  itera¬ 
tion/sprint. 

This  term  is  also  used  in  Traditional  World,  though  sometimes  called  the 
goal. 

The  vision  would  normally  be  captured  in  the  Traditional  World’s  project 
charter. 

How  is  it  used  in  Agile? 

Are  there  any  related  terms  or  concepts? 

Planning 

Charter'' “ 
{Traditional  World 
definition) 

Provides  authority  to  conduct  the  program  (within 
cost,  schedule,  and  performance  constraints);  as¬ 
signs  personnel  and  resources;  defines  the  PM’s 
line  of  authority  and  reporting  channels. 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods:  http://www.aspe-sdlc.com 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14“’  Edition,  July  201 1 
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Traditional  Terms:  Ball  Park  Estimate 


Definition''®'* 

Is  there  an  equivalent  in  the  Agile  World? 

Rough  estimate  made  with  some 
knowledge  and  confidence  that  the  esti¬ 
mated  figure  falls  within  a  reasonable 
range  of  values,  (i.e.,  this  estimate  is  at 
least  somewhere  in  the  ball  park  This 

is  based  upon  expert  judgment  gained 
from  experience. 

Also  called  rough  order  of  magnitude. 

Ball  park  estimates  are  normally  done  using  analogous  estimating  (see 
below),  which  uses  the  experience  from  previous  projects  and  extrapo¬ 
lates  that  onto  the  current  project.  In  agile  this  technique  is  call  relative 
estimation  (see  below). 

In  Agile,  initial  estimates  are  done  using  relative  estimation  with  tools 
such  as  planning  poker,  which  could  in  some  sense  be  thought  of  as  a 
very  thorough  ball  park  estimate. 

How  is  it  used  in  the  Traditional  World? 

Are  there  any  related  terms  or  concepts? 

Initial  budgeting  and  planning 

Relative  Estima¬ 
tion'®® 

(Agile  World  def¬ 
inition) 

A  technique  to  assess  size  and  complexity  by  com¬ 
paring  the  work  under  consideration  to  the  size  and 
complexity  of  other  known  requirements  and  work 
items. 

Cost  Estimate'®® 

A  judgment  or  opinion  regarding  expected  costs 
reached  using  an  estimating  process;  it  may  consti¬ 
tute  a  single  value  or  a  range  of  values. 

Analogous  Esti¬ 
mating'®'’ 

An  estimating  technique  that  uses  the  values  of 
parameters  (such  as  scope,  cost,  budget,  and  dura¬ 
tion)  or  measures  of  scale  (such  as  size,  weight, 
and  complexity)  from  a  previous,  similar  activity  as 
the  basis  for  estimating  the  same  parameter  or 
measure  for  a  future  activity. 

Parametric  Esti¬ 
mating'®® 

An  estimating  technique  that  uses  a  statistical  rela¬ 
tionship  between  historical  data  and  other  variables 
(e.g.,  lines  of  code)  to  calculate  an  estimate  for 
activity  parameters,  such  as  scope,  cost,  budget, 
and  duration. 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14“’  Edition,  July  201 1 

Term  and  definition(s)  adapted  whole  or  in  part  from 
http://www.agilebok.org/index.php?title=Relative_Prioritization_or_Ranking 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14*“  Edition,  July  201 1 

Terms  and  definition{s)  adapted  whole  or  in  part  from  PMBOK  Guide®-  Third  Edition 
Terms  and  definition{s)  adapted  whole  or  in  part  from  PMBOK  Guide®-  Third  Edition 
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Traditional  Terms:  Bar  Chart  (or  Gantt  Chart) 


Definition’'®® 

Is  there  an  equivalent  in  the  Agile  World? 

A  graphic  display  of  schedule-related  in¬ 
formation,  normally  with  activities  listed 
down  the  left  side  of  the  chart,  dates 
across  the  top,  and  activity  durations  are 
shown  as  horizontal  bars. 

Traditional  World  bar  or  Gantt  charts  do  not  have  a  direct  peer  in  Agile, 
but  the  concept  of  graphically  showing  work  assignments  or  other  activi¬ 
ties  or  efforts  across  a  calendar  is  found  in  both  worlds. 

Perhaps  the  closest  example  of  a  Gantt  chart  in  Agile  is  an  epic  board. 
The  epic  board  is  similar  to  a  story  or  task  board,  but  sits  one  level 
higher,  i.e.,  at  the  project/program/portfolio  level. 

How  is  it  used  in  the  Traditional  World? 

Are  there  any  related  terms  or  concepts? 

Bar  charts  are  used  throughout  the  life 
cycle,  but  primarily  in  pre-systems  acquisi¬ 
tion  (material  solution  analysis  and  tech¬ 
nology  development)  and  systems  acqui¬ 
sition  (engineering  and  manufacturing 
development  and  production  and  deploy¬ 
ment) 

Burn  -Up  Chart 
(or  Graph) 

(Agile  World  def¬ 
inition) 

A  visual  tool  displaying  progress  via  a  simple  line 
chart  representing  work  accomplished  (vertical  ax¬ 
is)  over  time  (horizontal  axis) 

Burn-up  charts  can  be  used  at  both  a  sprint  (or  iter¬ 
ation)  and  release  level. 

Burn-Down  Chart 
(or  Graph) 

(Agile  World  def¬ 
inition) 

A  visual  tool  displaying  progress  via  a  simple  line 
chart  representing  remaining  work  (vertical  axis) 
over  time  (horizontal  axis). 

Burn-down  charts  can  be  used  at  both  a  sprint  (or 
iteration)  and  release  level. 

Terms  and  definition{s)  adapted  whole  or  in  part  from  PMI  Glossary  Definitions 
http://www.timetrackingsoftware.com/help/dovtime10/pmi_glossary.htm 

Term  and  definition(s)  adapted  whole  or  in  part  from  http://www.telerik.com/agile-project-management- 
tools/agile-resources/vocabulary.aspx 

Term  and  definition(s)  adapted  whole  or  in  part  from  http://www.telerik.com/agile-project-management- 
tools/agile-resources/vocabulary.aspx 
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Traditional  Terms:  Critical  Path 


Definition”^ 

Is  there  an  equivalent  in  the  Agile  World? 

The  critical  path  is  the  “path”  through  a 
project  with  the  shortest  schedule  and 
where  the  activities  have  the  least  flexibil¬ 
ity  or  float.  As  such,  any  delay  to  an  activi¬ 
ty  on  the  critical  path  will  likely  delay  the 
project. 

The  Critical  Path  Method  is  a  technique 
that  aids  understanding  of  the  dependen¬ 
cy  of  events  in  a  project  and  the  time  re¬ 
quired  to  complete  them.  Activities  that, 
when  delayed,  have  an  impact  on  the  total 
project  schedule  are  critical  and  said  to  be 
on  the  critical  path. 

There  isn’t  a  direct  peer  in  Agile  due  to  the  different  planning  approach¬ 
es.  However,  the  Agile  roadmap  is  the  vehicle  to  coordinate  dependen¬ 
cies  across  releases,  and  the  Agile  release  plan  is  the  vehicle  to  coordi¬ 
nate  dependencies  across  sprints  or  iterations. 

Also,  when  working  with  a  multi-team  project,  epic  boards  can  be  used 
to  coordinate  story  dependencies  and  ensure  iteration  alignment  of  fea¬ 
tures. 

How  is  it  used  in  the  Traditional  World? 

Are  there  any  related  terms  or  concepts? 

Planning 

Backward 

Pass^^^ 

Calculating  late  finish  dates  and  late  start  dates  for 
uncompleted  activities  by  working  backwards 
through  the  schedule  network  logic  from  the  pro¬ 
ject's  end  date 

Forward  Pass^^'* 

Calculating  early  start  and  early  finish  dates  for 
uncompleted  activities. 

Network  Logic^^® 

The  collection  of  schedule  activity  dependencies 
that  makes  up  a  project  schedule  network  diagram. 

Project  Schedule 
Network  Dia- 
gram^^® 

A  schematic  display  of  the  logical  relationships 
among  the  project  schedule  activities,  and  always 
drawn  from  left  to  right  to  reflect  project  work  chro¬ 
nology. 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14“’  Edition,  July  201 1 

Terms  and  definition{s)  adapted  whole  or  in  part  from  PMBOK  Guide®-  Third  Edition 
Terms  and  definition{s)  adapted  whole  or  in  part  from  PMBOK  Guide®  -  Third  Edition 
Terms  and  definition{s)  adapted  whole  or  in  part  from  PMBOK  Guide®-  Third  Edition 
Terms  and  definition{s)  adapted  whole  or  in  part  from  PMBOK  Guide®-  Third  Edition 
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Traditional  Terms:  Derived  Requirements 


Definition’’’'^ 

Is  there  an  equivalent  in  the  Agile  World? 

A  lower-level  requirement  that  is  deter¬ 
mined  to  be  necessary  for  a  top-level  re¬ 
quirement  to  be  met. 

This  term  means  essentially  the  same  in  both  the  Traditional  World  and 
Agile. 

In  Agile,  this  is  often  referred  to  as  splitting  user  stories,  and  these  are 
uncovered  during  many  stages  in  the  development,  and  are  fed  into 
the  backlog  for  active  consideration  for  the  next  release  or  itera¬ 
tion/sprint. 

In  the  Traditional  World,  however,  they  must  (in  theory)  all  be  discov¬ 
ered  and  articulated  at  project  start  as  part  of  the  requirements  refine¬ 
ment  and  architectural  design  processes. 

How  is  it  used  in  the  Traditional  World? 

Are  there  any  related  terms  or  concepts? 

During  the  user  needs  phase,  and  possibly 
into  the  technology  opportunities  and  re- 
sources  phase. 

Requirement"® 

A  condition  or  capability  needed  by  a  user  to  solve 
a  problem  or  achieve  an  objective. 

Quality  Attrib¬ 
ute"® 

A  requirement  that  specifies  the  degree  of  an  at¬ 
tribute  that  affects  the  quality  that  the  system  or 
software  must  possess,  such  as  performance, 
modifiability,  usability. 

Story  (or  User 
Story) 

(Agile  World 
definition) 

Often  written  on  3”  x  5”  cards,  a  story  (or  user  sto¬ 
ry)  is  a  high-level  requirement  definition  written  in 
everyday  or  business  language. 

Terms  and  definition{s)  adapted  whole  or  in  part  from  ISA/IEC/IEEE  24765  Systems  and  Software  Engineering 

-  Vocabulary,  December  15,  2010 

Terms  and  definition{s)  adapted  whole  or  in  part  from  ISA/IEC/IEEE  24765  Systems  and  Software  Engineering 

-  Vocabulary,  December  15,  2010 

Terms  and  definition{s)  adapted  whole  or  in  part  from  ISA/IEC/IEEE  24765  Systems  and  Software  Engineering 

-  Vocabulary,  December  15,  2010 

Term  and  definition(s)  adapted  whole  or  in  part  from  http://www.telerik.com/agile-project-management- 
tools/agile-resources/vocabulary.aspx 
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Traditional  Terms:  Earned  Value  Management  (EVM) 


Definition’’^’' 

Is  there  an  equivalent  in  the  Agile  World? 

A  method  combining  scope,  schedule,  and 
resource  data  into  a  measure  of  perfor¬ 
mance  and  progress  by  comparing  what 
was  budgeted  for  a  task  (time  and  re¬ 
sources)  against  what  the  task  actually 
required  (time  and  resources). 

Typically,  it  is  difficult  to  use  the  Traditional  waterfall-related  concepts  of 
earned  value  management  (EVM)  in  Agile.  However,  Rawsthorne^^^ 
proposes  how  a  functional  work  breakdown  structure  (WBS)  can  pro¬ 
vide  a  structure  for  business  metrics  (business  value,  earned  business 
value),  which  when  combined  with  burn-down  charts  can  provide  a 
good,  composite  understanding  of  the  progress  of  a  project. 

How  is  it  used  in  the  Traditional  World? 

Are  there  any  related  terms  or  concepts? 

EVM  can  be  used  throughout  the  life  cy¬ 
cle,  but  is  primarily  used  during 

•  Pre-Systems  Acquisition  (Material 
Solution  Analysis  and  Technology 
Development) 

•  Systems  Acquisition  (Engineering  and 
Manufacturing  Development  and  Pro¬ 
duction  and  Deployment) 

•  Sustainment  (Operations  and  Sup¬ 
port) 

Actual  Cost  of 
Work  Performed 

(ACWP)^23 

The  costs  actually  incurred  and  recorded  in  accom¬ 
plishing  the  work  performed  within  a  given  time 
period. 

Budget  at 
Completion 
(BAC)  '24 

The  sum  of  all  the  budgets  for  the  work  to  be  per¬ 
formed  on  a  project;  can  also  be  done  for  a  work 
breakdown  structure  component  or  for  a  schedule 
activity. 

Cost  Perfor¬ 
mance  Index 

(CPI)  125 

The  ratio  of  earned  value  to  actual  costs. 

Estimate  at 
Completion 
(EAC)  126 

The  expected  total  cost  when  the  defined  scope  of 
work  has  been  completed;  most  EAC  forecasts 
adjust  the  original  cost  estimate  based  on  actual 
performance  to  date. 

Schedule  Per¬ 
formance  Index 
(SPI)i2i' 

A  measure  of  schedule  efficiency  on  a  project;  it  is 
the  ratio  of  earned  value  (EV)  to  planned  value 
(PV). 

Terms  and  definition{s)  adapted  whole  or  in  part  from  PMBOK  Guide®  -  Third  Edition 

Discussion  adapted  from  http://www.agilejournal.com/articles/columns/column-articles/54-calculating-earned- 
business-value-for-an-agile-project 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14"’  Edition,  July  201 1 

Terms  and  definition{s)  adapted  whole  or  in  part  from  PMBOK  Guide®  -  Third  Edition 

Terms  and  definitionjs)  adapted  whole  or  in  part  from  PMI  Glossary  Definitions 
http://www.timetrackingsoftware.com/help/dovtime10/pmi_glossary.htm 

Terms  and  definition{s)  adapted  whole  or  in  part  from  ISA/IEC/IEEE  24765  Systems  and  Software  Engineering 
-  Vocabulary,  December  15,  2010 

Terms  and  definition{s)  adapted  whole  or  in  part  from  PMBOK  Guide®  -  Third  Edition 
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Traditional  Terms:  Entry  Criteria/Exit  Criteria 


Definition’’^® 

Is  there  an  equivalent  in  the  Agile  World? 

Entry  Criteria  -  The  state  of  being  that 
must  be  present  before  an  effort  can  begin 
successfully. 

While  the  terms  are  not  in  as  common  use  in  Agile  as  they  are  in  the 
Traditional  World,  the  concept  that  there  are  criteria  that  must  be  met 
before  an  effort  can  start  is  a  management  tenant  in  both  worlds. 

Exit  Criteria  -  The  state  of  being  that  must 
be  present  before  an  effort  can  end  suc¬ 
cessfully. 

For  example,  one  entry  criteria  for  a  sprint  or  iteration  is  a  ready  product 
backlog,  which  is  a  backlog  that  is  broken  down  into  small  pieces,  which 
are  clear  to  the  developers,  immediately  actionable,  estimated  in  points 
by  the  team  that  will  implement  it,  and  testable. 

Exit  Criteria  are  also  related  to  the  Agile  concept  of  “done.” 

How  is  it  used  in  the  Traditional  World? 

Are  there  any  related  terms  or  concepts? 

Used  for  planning  gates  and  reviews. 

Done 

(Agile  World  def¬ 
inition) 

Defined  differently  at  different  stages  of  a  project, 
done  means  within  the  context  where  the  term  is 
understood  and  accepted — that  everything  needed 
to  advance  to  the  next  stage  (be  that  to  the  next 
day’s  work,  the  next  sprint  (or  iteration),  or  release 
is  complete. 

Done  Done 
(Agile  World  def¬ 
inition) 

Done  done  means  that  all  of  the  tasks  needed  to 
create  the  final,  releasable  product  have  been 
completed. 

Terms  and  definition{s)  adapted  whole  or  in  part  from  ISA/IEC/IEEE  24765  Systems  and  Software  Engineering 
-  Vocabulary,  December  15,  2010 
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Traditional  Terms:  Fund 

tion  Point 

Definition’’^® 

Is  there  an  equivalent  in  the  Agile  World? 

A  unit  of  measure  for  functional  size  that 
looks  at  the  logical  view: 

•  El  -  external  inputs 

•  EO  -  external  outputs 

•  EQ  -  external  inquiries 

•  EIF  -  external  interface  files 

•  ILF  -  internal  logical  files 

Flowever,  function  points  do  not  count 
things  like  coding  algorithms  or  database 
structure. 

This  concept  has  utility  in  both  the  Traditional  World  and  Agile  (though 
the  use  and  application  of  function  points  is  not  universally  or  consist¬ 
ently  used). 

How  is  it  used  in  the  Traditional  World? 

Are  there  any  related  terms  or  concepts? 

When  used,  Function  Points  are  primarily 

used  during  : 

•  Pre-Systems  Acquisition  {Technol¬ 
ogy  Development) 

•  Systems  Acquisition  {Engineering 
and  Manufacturing  Deveiopment  and 
Production  and  Depioyment) 

•  Sustainment  (Operations  and  Sup¬ 
port) 

Complexity 

Points 

(Agiie  Worid  def¬ 
inition) 

Complexity  Points  are  units  of  measure  used  to 
estimate  development  work  in  terms  of  complexity, 
but  not  effort — effort  is  measured  by  story  points. 

Terms  and  definition{s)  adapted  whole  or  in  part  from  http://www.functionpoints.org 
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Traditional  Terms:  Increment 


Definition’'^® 

Is  there  an  equivalent  in  the  Agile  World? 

A  militarily  useful  capability  that  can  be 
developed,  produced,  acquired,  deployed 
and  sustained;  increments  each  have  their 
own  user-defined  threshold  and  objective 
values. 

While  the  underlying  concept  is  similar  (a  useful  capability  or  an  added 
value),  a  Traditional  World  increment  is  normally  much  larger  than  an 
Agile  increment. 

How  is  it  used  in  the  Traditional  World? 

Are  there  any  related  terms  or  concepts? 

The  concept  of  increments  can  be  used 
throughout  the  life  cycle  but  are  most  used 
during: 

•  Pre-Systems  Acquisition  {Material 
Solution  Analysis  and  Technology 
Development) 

•  Systems  Acquisition  {Engineering 
and  Manufacturing  Development  and 
Production  and  Deployment) 

•  Sustainment  (Operations  and  Sup¬ 
port) 

Increment'^' 

(Agile  World  def¬ 
inition) 

Agile  software  projects  deliver  the  system  in  incre¬ 
ments,  which  represent  the  value  added  to  the  sys¬ 
tem  such  as  newly  implemented  features,  removed 
defects,  or  an  improved  user  experience. 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14*’’  Edition,  July  201 1 

Terms  and  definition{s)  adapted  whole  or  in  part  from  http://my.safaribooksonline.com/book/software- 
engineering-and-development/agile-development/9780735625679/return-on-investment/increment 
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Traditional  Terms:  Inspection 


Definition’’^^ 

Is  there  an  equivalent  in  the  Agile  World? 

Visual  examination  of  an  item  and  associ¬ 
ated  documentation  comparing  it  to  prede¬ 
termined  standards  to  determine  conform¬ 
ance;  does  not  require  the  use  of  special 
laboratory  equipment  or  procedures. 

This  term  means  essentially  the  same  (for  a  product)  in  both  the  Tradi¬ 
tional  World  as  in  Agile.  In  the  Agile  method  Scrum,  however,  it  also 
relates  to  the  Scrum  process  itself. 

In  Agile,  a  product  being  “ready  for  inspection”  is  more  subjective  be¬ 
cause  of  the  iterative  nature  of  the  development  and  the  fact  that  prod¬ 
ucts  are  continuously  evolving.  Therefore  a  product  should  be  consid¬ 
ered  ready  for  inspection  when  it  is  "finished"  for  the  time  being  (as  in  a 
sprint  demonstration,  for  example).  Note  that  finished  does  not  neces¬ 
sarily  mean  “done”  as  more  work  on  that  product  may  be  planned,  but  it 
does  mean  that  it  is  in  a  stable  state. 

Some  Agile  teams  add  an  additional  column  or  phase  to  their  story 
board  for  team  inspections  or  peer  reviews,  requiring  that  all  code  be 
inspected  before  it  can  be  declared  done. 

How  is  it  used  in  the  Traditional  World? 

Are  there  any  related  terms  or  concepts? 

Inspections  are  most  used  during: 

•  Pre-Systems  Acquisition  {Material 
Solution  Analysis  and  Technology 
Development) 

•  Systems  Acquisition  {Engineering 
and  Manufacturing  Development  and 
Production  and  Deployment) 

•  Sustainment  (Operations  and  Sup- 
port) 

Inspection'' 

(Agile  World  def¬ 
inition) 

Assessment  to  determine  if  a  process  has  deviated 
outside  acceptable  limits;  four  formal  opportunities 
in  Scrum: 

•  Sprint  Planning  meeting 

•  Daily  Scrum 

•  Sprint  review 

•  Sprint  Retrospective 

Peer  Review^-^® 

A  review  of  work  products  performed  by  peers  dur¬ 
ing  development  of  the  work  products  to  identify 
defects  for  removal. 

Structured 

Walkthrough^®® 

A  systematic  examination  of  the  requirements,  de¬ 
sign,  or  implementation  of  a  system,  or  any  part  of 
it,  by  qualified  personnel. 

Terms  and  definition{s)  adapted  whole  or  in  part  from 
Terms,  14*’’  Edition,  July  201 1 

Terms  and  definition{s)  adapted  whole  or  in  part  from 

Terms  and  definition{s)  adapted  whole  or  in  part  from 
of  the  Game;  Schwaber  and  Sutherland,  scruminc 

Terms  and  definition{s)  adapted  whole  or  in  part  from 

-  Vocabulary,  December  15,  2010 

Terms  and  definition{s)  adapted  whole  or  in  part  from 

-  Vocabulary,  December  15,  2010 


DAU  Glossary  of  Defense  Acquisition  Acronyms  and 

DSDM  Public  Version  4.2 

The  Scrum  Guide  -  The  Definitive  Guide  to  Scrum:  Rules 

ISA/IEC/IEEE  24765  Systems  and  Software  Engineering 
ISA/IEC/IEEE  24765  Systems  and  Software  Engineering 
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Traditional  Terms:  Integrated  Master  Plan/Integrated  Master  Schedule 


Definition’’^^ 

Is  there  an  equivalent  in  the  Agile  World? 

Integrated  Master  Plan  (IMP)  -  An  event- 
driven  plan  capturing  the  major  accom¬ 
plishments  necessary  to  complete  a  body 
of  work  that  ties  each  accomplishment  to 
a  key  program  event. 

Integrated  Master  Schedule  (IMS)  -  An 
integrated  schedule  of  the  tasks  needed  to 
complete  the  work  effort  captured  in  the 
IMP;  the  IMS  should  include  all  IMP 
events  and  accomplishments. 

When  taken  in  their  total,  Agile’s  five  levels  of  planning  (product  vision, 
product  roadmap,  release  plan(s),  sprint  (or  iteration)  plan(s),  and  daily 
commitment(s))  match  or  perhaps  even  exceed  the  information  in  a 
Traditional  World  IMP  and  IMS. 

Also,  an  epic  board  can  be  used  to  visualize  an  integrated  Agile  plan. 

How  is  it  used  in  the  Traditional  World? 

Are  there  any  related  terms  or  concepts? 

The  IMP  and  IMS  can  be  used  throughout 

the  life  cycle  but  are  most  used  during: 

•  Pre-Systems  Acquisition  {Material 
Solution  Analysis  and  Technology 
Development) 

•  Systems  Acquisition  {Engineering 
and  Manufacturing  Development  and 
Production  and  Deployment) 

•  Sustainment  (Operations  and  Sup¬ 
port) 

Schedule  Devel- 
opmenf®® 

The  process  of  creating  the  project  schedule  by 
analyzing  activity  sequences,  activity  durations, 
resource  requirements,  and  schedule  constraints 

Roadmap^^® 

(Agile  World  def¬ 
inition) 

The  roadmap  distills  the  vision  into  a  high  level  plan 
that  outlines  work  spanning  one  or  more  releases; 
requirements  are  grouped  into  prioritized  themes, 
each  with  an  execution  estimate. 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAD  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14*’’  Edition,  July  201 1 

Terms  and  definition{s)  adapted  whole  or  in  part  from  ISA/IEC/IEEE  24765  Systems  and  Software  Engineering 
-  Vocabulary,  December  15,  2010 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods]  http://www.aspe-sdlc.com 
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Traditional  Terms:  Integrated  Product  Team  (IPT) 


Definition'' 

Is  there  an  equivalent  in  the  Agile  World? 

Multi-disciplinary  teams  to  identify,  explore 
and  resolve  issues,  and  to  provide  rec¬ 
ommendations  to  decision  makers. 

•  Working-level  IPTs  (WIPTs)  fo¬ 
cus  on  program  issues  and  sta¬ 
tus,  identify  risks,  and  seek  im¬ 
provement  opportunities. 

•  Overarching  IPTs  (OIPTs)  focus 
on  strategic  guidance,  program 
assessment,  and  issue  resolu¬ 
tion. 

•  Program-level  IPTs  (PIPTs)  fo¬ 
cus  on  program  execution  and 
may  include  both  government 
and  contractor  representatives. 

The  term  means  the  same  in  Agile;  however  in  Agile  there  is  a  signifi¬ 
cantly  greater  emphasis  placed  on  the  team  with  regard  to  planning; 
they  have  a  much  greater  voice  and  are  much  more  active. 

Perhaps  the  best  peer  term  in  Agile  is  cross  functional  teams,  which  are 
groups  of  people  who  collectively  represent  the  entire  organization’s 
interests  in  a  specific  product  or  product  family.''" 

How  is  it  used  in  the  Traditional  World? 

Are  there  any  related  terms  or  concepts? 

IPTs  are  used  in  all  aspects  of  Traditional 
waterfall. 

Feature 

Teams'''^ 

(Agile  World  def¬ 
inition) 

Small,  cross-functional  teams  focused  on  designing 
and  building  specific  feature  groupings. 

Stakeholder''*® 

An  individual,  group,  or  organization  who  may  af¬ 
fect,  be  affected  by,  or  perceive  itself  to  be  affected 
by  a  project’s  activities,  products,  or  services. 

Red  Team''*'* 

Red  teams  are  groups  of  experts  brought  in  by  an 
enterprise  to  challenge  plans,  programs,  assump¬ 
tions,  etc.  as  well  as  to  play  devil’s  advocate  and 
related  roles. 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14*’’  Edition,  July  201 1 

Adapted  whole  in  in  part  from  http://theagileproductmanager.blogspot.eom/2008/07/whats-cross-functional- 
team-and-why.html 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods:  http://www.aspe-sdlc.com 

Terms  and  definition{s)  adapted  whole  or  in  part  from  ISA/IEC/IEEE  24765  Systems  and  Software  Engineering 
-  Vocabulary,  December  15,  2010 

Terms  and  definition{s)  adapted  whole  or  in  part  from  The  Final  Report  of  the  Defense  Science  Board  Task 
Force  on  the  Role  and  Status  of  DoD  Red  Teaming  Activities 
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Traditional  Terms:  Key  Performance  Parameters  (KPPs) 


Definition''^® 

Is  there  an  equivalent  in  the  Agile  World? 

A  critical  or  essential  system  characteris¬ 
tic;  normally  has  a  threshold  and  an  objec¬ 
tive  value. 

While  there  is  no  direct  equivalent  or  peer  for  this  term  in  the  Agile 

World,  this  type  of  information  is  critical  to  both  the  Traditional  World 
and  the  Agile  World. 

In  Agile,  this  information  is  normally  captured  in  Agile  stories  (or  user 
stories),  though  the  concept  of  technical  user  stories  (those  created  by 
the  development  teams  rather  than  those  created  by  the  product  owner) 
is  contentious  within  Agile. 

How  is  it  used  in  the  Traditional  World? 

Are  there  any  related  terms  or  concepts? 

Planning  and  Testing 

Requirements 

Analysis''*® 

Definition  and  refinement  of  system,  subsystem, 
and  lower-level  functional  and  performance  re¬ 
quirements  and  interfaces  to  facilitate  the  architec¬ 
ture  design  process;  establishes  the  detailed  func¬ 
tional,  interface,  and  temporal  aspects  of  the 
system  to  unambiguously  communicate  system 
behavior  in  its  intended  environment,  and  the  de¬ 
velopment  of  lower  tier  functional  and  performance 
requirements  that  need  to  be  allocated  to  the  sys¬ 
tem  physical  architecture. 

Performance 

Specification*'*'' 

A  document  that  specifies  the  performance  charac¬ 
teristics  that  a  system  or  component  must  possess. 

Quality  Attrib¬ 
ute*'*® 

A  requirement  that  specifies  the  degree  of  an  at¬ 
tribute  that  affects  the  quality  that  the  system  or 
software  must  possess,  such  as  performance,  mod¬ 
ifiability,  usability. 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAD  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14*’’  Edition,  July  201 1 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14*’’  Edition,  July  201 1 

Terms  and  definition{s)  adapted  whole  or  in  part  from  ISA/IEC/IEEE  24765  Systems  and  Software  Engineering 

-  Vocabulary,  December  15,  2010 

Terms  and  definition{s)  adapted  whole  or  in  part  from  ISA/IEC/IEEE  24765  Systems  and  Software  Engineering 

-  Vocabulary,  December  15,  2010 
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Traditional  Terms:  Lightweight  Process 


Definition’'^® 

Is  there  an  equivalent  in  the  Agile  World? 

A  process  with  a  single  thread  of  control;  a 
task. 

This  is  a  heavily  loaded  term,  as  Agile  development  methods  are  fre¬ 
quently  characterized  as  “lightweight”  and  traditional  as  “heavyweight.” 

However,  the  underlying  concept  is  valid  in  both  the  Traditional  World 
and  Agile. 

How  is  it  used  in  the  Traditional  World? 

Are  there  any  related  terms  or  concepts? 

Both  the  concept  of  lightweight  and  heav¬ 
yweight  processes  are  normally  used  dur¬ 
ing: 

•  Pre-Systems  Acquisition  {Technol¬ 
ogy  Development) 

•  Systems  Acquisition  {Engineering 
and  Manufacturing  Development) 

Process'®® 

The  combination  of  people,  equipment,  materials, 
methods,  and  environment  that  produces  a  given 
product  or  service. 

Heavyweight 

Process'®' 

A  process  with  its  own  memory  and  multiple 
threads  of  control 

Terms  and  definition{s)  adapted  whole  or  in  part  from  ISA/IEC/IEEE  24765  Systems  and  Software  Engineering 

-  Vocabulary,  December  15,  2010 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14*’’  Edition,  July  201 1 

Terms  and  definition{s)  adapted  whole  or  in  part  from  ISA/IEC/IEEE  24765  Systems  and  Software  Engineering 

-  Vocabulary,  December  15,  2010 
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Traditional  Terms:  Miles 

tone  A/Milestone  B/Milestone  C 

Definition’'®^ 

Is  there  an  equivalent  in  the  Agile  World? 

A  scheduled  event  used  to  measure  pro¬ 
gress; 

•  Milestone  A  precedes  a  program 
moving  into  Technology  Devel¬ 
opment  (TD) 

•  Milestone  B  precedes  a  program 
moving  into  the  Engineering  and 
Manufacturing  Development 
(EMD) 

•  Milestone  C  precedes  a  program 
moving  into  Production  and  De¬ 
ployment  (P&D) 

This  term  means  the  same  thing  for  a  program  in  the  Traditional  World 
as  well  as  a  program  using  an  Agile  method.  However,  the  data  and 
documents  normally  required  in  the  Traditional  World  normally  exceed 
that  which  is  produced  in  Agile  (though  Agile  does  produce  the  data  and 
documents  to  address  the  primary  intent  of  the  milestones — is  the  pro¬ 
gram  ready  to  proceed?) 

However,  when  these  concepts  are  used  in  an  Agile  World,  care  needs 
to  be  taken  that  the  inherent  conflicts  are  addressed  so  not  to  impact 
the  program  with  unnecessary  documentation  while  ensuring  that  es¬ 
sential  documents  are  still  included. 

How  is  it  used  in  the  Traditional  World? 

Are  there  any  related  terms  or  concepts? 

Milestone  decision  points  are  fundamental 
to  planning  and  management  of  programs 

Technology  De¬ 
velopment 
Phase'®® 

Designed  to  reduce  technology  risk  and  to  deter¬ 
mine  the  appropriate  set  of  technologies  to  be  inte¬ 
grated  into  the  full  system. 

Engineering  and 
Manufacturing 
Development 
Phase'®'' 

Consists  of  integrated  system  design  (ISD)  and 
system  capability  and  manufacturing  process 
demonstration  (SC&MPD). 

Production  and 

Deployment 

Phase'®® 

Designed  to  achieve  an  operational  capability  that 
satisfies  the  mission  need,  this  phase  consists  of 
low-rate  initial  production  (LRIP)  and  full-rate  pro¬ 
duction  and  deployment  (FRP&D)  separated  by  a 
full-rate  production  decision  review  (FRPDR). 

Terms  and  definition{s)  adapted  whole  or  in  part  from  ISA/IEC/IEEE  24765  Systems  and  Software  Engineering 
-  Vocabulary,  December  15,  2010 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAD  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14*’’  Edition,  July  201 1 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAD  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14*’’  Edition,  July  201 1 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAD  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14“’  Edition,  July  201 1 
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Traditional  Terms:  Oversight 


Definition’’®® 

Is  there  an  equivalent  in  the  Agile  World? 

Review  activity  by  the  Office  of  the  Secre¬ 
tary  of  Defense  (OSD),  the  Joint  Staff 
(JS),  DoD  Components,  and  congression¬ 
al  committees  of  DoD  programs  to  deter¬ 
mine  current  status,  ascertain  if  the  law  or 
other  desires  of  Congress  are  being  fol¬ 
lowed,  or  as  a  basis  for  possible  future 
legislation. 

Programs  are  subject  to  oversight  whether  they  are  in  the  Traditional 
World  or  in  the  Agile  World.  However,  with  the  passage  of  such  legisla¬ 
tion  as  the  NDAA  of  2010  Section  804  and  efforts  such  as  the  USN’s  IT 
Streamlining,  the  form  of  oversight  will  often  vary  depending  on  the 
whether  the  project  is  using  traditional  or  Agile  methods. 

How  is  it  used  in  the  Traditional  World? 

Are  there  any  related  terms  or  concepts? 

Oversight  is  fundamental  to  planning  and 
management  of  programs. 

Review’’®^ 

A  process  or  meeting  during  which  a  work  product, 
or  set  of  work  products,  is  presented  to  project  per¬ 
sonnel,  managers,  users,  customers,  or  other  inter¬ 
ested  parties  for  comment  or  approval. 

Material  Devel¬ 
opment  Deci- 
sion’’®® 

Formal  entry  point  into  the  acquisition  process  that 
normally  requires  an  initial  capabilities  document 
(ICD)  and  study  guidance  for  the  analysis  of  alter¬ 
natives  (AoA). 

Critical  Design 
Review’’®® 

A  multi-discipline  technical  review  to  ensure  that  a 
system  can  proceed  into  fabrication,  demonstration, 
and  test,  and  can  meet  stated  performance  re¬ 
quirements  within  cost,  schedule,  risk,  and  other 
system  constraints. 

Full-Rate  Produc¬ 
tion  Decision 
Review’’®® 

A  review  conducted  at  the  conclusion  of  low-rate 
initial  production  (LRIP)  effort  that  authorizes  entry 
into  the  full-rate  production  (FRP). 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14*’’  Edition,  July  201 1 

Terms  and  definition{s)  adapted  whole  or  in  part  from  ISA/IEC/IEEE  24765  Systems  and  Software  Engineering 
-  Vocabulary,  December  15,  2010 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14*’’  Edition,  July  201 1 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14*’’  Edition,  July  201 1 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14“’  Edition,  July  201 1 
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Traditional  Terms:  Peer 

Review 

Definition''®’' 

Is  there  an  equivalent  in  the  Agile  World? 

A  review  of  work  products  performed  by 
peers  during  development  of  the  work 
products  to  identify  defects  for  removal. 

Paired  programming  is  a  specific  type  of  peer  review  used  in  Agile 
(most  consistently  in  extreme  programming). 

However,  while  the  concept  of  peers  participating  in  all  phases  of  plan¬ 
ning,  design,  execution,  and  review  is  fundamental  to  several  Agile 
methods,  peer  reviews  are  generally  confined  to  product  review  in  the 
Traditional  World. 

How  is  it  used  in  the  Traditional  World? 

Are  there  any  related  terms  or  concepts? 

Peer  review  is  used  during  the  develop¬ 
ment  process 

Pair  Program- 
ming'®2 

(Agiie  Worid  def¬ 
inition) 

Two  developers  (sometimes  referred  to  as  the 
“driver”  for  the  person  actually  coding  and  the  “ob¬ 
server”)  working  side-by-side  to  create  a  single 
feature;  it  provides  real-time  code  review,  allows 
one  developer  to  think  ahead  while  the  other  thinks 
about  the  work  at  hand,  and  supports  cross¬ 
training. 

The  concept  can  also  extend  to  pair  designing  and 
pair  unit  testing.  It  provides  real  time  peer  reviews. 

Inspection'®® 

Visual  examination  of  an  item  and  associated  doc¬ 
umentation  comparing  it  to  predetermined  stand¬ 
ards  to  determine  conformance;  does  not  require 
the  use  of  special  laboratory  equipment  or  proce¬ 
dures. 

''®''  Terms  and  definition{s)  adapted  whole  or  in  part  from  ISA/IEC/IEEE  24765  Systems  and  Software  Engineering 
-  Vocabulary,  December  15,  2010 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods:  http://www.aspe-sdlc.com 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAD  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14“’  Edition,  July  201 1 
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Traditional  Terms:  Performance  Measurement  Baseline  (PMB) 


Definition^®'* 

Is  there  an  equivalent  in  the  Agile  World? 

An  integrated  scope-schedule-cost  plan 
for  the  project  work  against  which  project 
execution  is  compared  to  measure  and 
manage  performance. 

The  closest  concept  for  this  is  velocity,  which  like  the  performance 
measurement  baseline  is  a  relative  measure  of  how  much  work  is  ac¬ 
complished  by  the  team.  A  release  plan  can  also  be  viewed  as  a  high- 
level  PMB. 

In  Agile,  the  velocity  calculated  as  the  number  of  story  points  associated 
with  stories  (or  user  stories)  that  are  finished  by  a  team  over  a  given 
period  of  time. 

burn-down  charts — which  graphically  show  how  much  work  remains  or 
how  much  work  has  been  “burned  down”  over  time — and  burn-up 
charts — which  are  the  same  except  they  show  how  much  work  has 
been  accomplished  over  time —  are  also  very  similar. 

How  is  it  used  in  the  Traditional  World? 

Are  there  any  related  terms  or  concepts? 

The  performance  measurement  baseline 
is  used  throughout  the  life  cycle  but  is 
most  used  during: 

•  Pre-Systems  Acquisition  {Ma¬ 
terial  Solution  Analysis  and 
Technology  Development) 

•  Systems  Acquisition  {Engineer¬ 
ing  and  Manufacturing  Develop¬ 
ment  and  Production  and  De¬ 
ployment) 

•  Sustainment  (Operations  and 
Support) 

Burn  -Up  Chart 
(or  Graph) 

(Agile  World  def¬ 
inition) 

A  visual  tool  displaying  progress  via  a  simple  line 
chart  representing  work  accomplished  (vertical  ax¬ 
is)  over  time  (horizontal  axis) 

Burn-up  charts  are  also  normally  used  at  a  release 
level  as  well  as  the  sprint  (or  Iteration)  levels. 

Agile  burn-up  charts  are  conceptually  equivalent  to 
the  Traditional  World’s  Earned  Value  accumulated 
at  a  specific  date  [Cabri  2006]. 

Burn-Down  Chart 
(or  Graph)  *®® 
(Agile  World  def¬ 
inition) 

A  visual  tool  displaying  progress  via  a  simple  line 
chart  representing  remaining  work  (vertical  axis) 
over  time  (horizontal  axis). 

Burn-down  charts  can  be  used  at  both  a  sprint  (or 
iteration)  and  release  level. 

Performance 

Indicator*®'' 

An  assessment  indicator  that  supports  the  judg¬ 
ment  of  the  process  performance  of  a  specific  pro¬ 
cess. 

Terms  and  definition{s)  adapted  whole  or  in  part  from  PMBOK  Guide®-  Third  Edition 

Term  and  definition(s)  adapted  whole  or  in  part  from  http://www.telerik.com/agile-project-management- 
tools/agile-resources/vocabulary.aspx 

Term  and  definition(s)  adapted  whole  or  in  part  from  http://www.telerik.com/agile-project-management- 
tools/agile-resources/vocabulary.aspx 

Terms  and  definitionjs)  adapted  whole  or  in  part  from  ISA/IEC/IEEE  24765  Systems  and  Software  Engineering 
-  Vocabulary,  December  15,  2010 
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Traditional  Terms:  Preplanned  Product  Improvement  (P^l) 


Definition’’^ 

Is  there  an  equivalent  in  the  Agile  World? 

Planned  future  improvement  of  develop¬ 
mental  systems  for  which  design  consid¬ 
erations  are  effected  during  development 
to  enhance  future  application  of  projected 
technology. 

Includes  improvements  planned  for  ongo¬ 
ing  systems  that  go  beyond  the  current 
performance  envelope  to  achieve  a  need¬ 
ed  operational  capability. 

While  there  is  some  credence  to  the  notion  that  Agile  methods  are  simi¬ 
lar  to  P^l  in  that  Agile  methods  stress  delivering  the  highest  priority  re¬ 
quirements  first,  P’^l  itself  remains  firmly  rooted  in  the  Traditional  World 
as  the  improvements  are  all  planned  up  front. 

When  applying  Agile  methods,  the  concept  of  P’^l  can  be  used  to  reduce 
long  term  refactoring  costs  or  technical  debt.  However,  this  must  be 
balanced  against  the  Agile  tenet  of  simpiicity — maximizing  the  amount 
of  work  not  done. 

How  is  it  used  in  the  Traditional  World? 

Are  there  any  related  terms  or  concepts? 

Preplanned  product  improvement  con¬ 
cepts  can  be  used  throughout  the  life  cy- 
ole  but  are  most  used  during: 

•  Pre-Systems  Acquisition 

(Technology  Development) 

•  Systems  Acquisition  (Engineer¬ 
ing  and  Manufacturing  Deveiop- 
ment  and  Production  and  De- 
pioyment) 

•  Sustainment  (Operations  and 
Support) 

Big  Design  Up 
Front  (BDUF) 

An  extensive  up-front  design  effort  which  many 
Agilists  see  as  the  hallmark  of  Traditional  waterfall. 

Product 

Improvement  (PI) 

169 

Effort  to  incorporate  a  configuration  change  involv¬ 
ing  engineering  and  testing  effort  on  end  items  and 
depot  repairable  components,  or  changes  on  other- 
than-developmental  items  to  increase  system  or 
combat  effectiveness  or  extend  useful  military  life. 
Usually  results  from  feedback  from  the  users. 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14*’’  Edition,  July  201 1 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14“’  Edition,  July  201 1 
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Traditional  Terms:  Program  Evaluation  and  Review  Technique  (PERT) 


Definition’’™ 

Is  there  an  equivalent  in  the  Agile  World? 

A  technique  for  management  of  a  program 
through  to  completion  by  constructing  a 
network  model  of  integrated  activities  and 
events  and  periodically  evaluating  the 
time/cost  implications  of  progress. 

There  is  no  peer  per  se  in  Agile.  However,  Agile  does  present  the  op¬ 
portunity  to  associate  stories  (or  user  stories)  that  have  dependencies 
on  one  another  in  the  release  plan.  However,  this  is  balanced  against 
the  goal  that  stories  (or  user  stories)  are  able  to  stand  alone  and  not  be 
interdependent. 

How  is  it  used  in  the  Traditional  World? 

Are  there  any  related  terms  or  concepts? 

The  PERT  technique  and  charts  are  used 
throughout  the  life  cycle. 

PERT  Chart^^'i 

A  graphic  portrayal  of  milestones,  activities,  and 
their  dependency  upon  other  activities  for  comple¬ 
tion  and  depiction  of  the  critical  path. 

Story  Maps^'’^ 
(Agile  World  def¬ 
inition) 

A  visual  technique  to  prioritize  Stories  (or  User  Sto¬ 
ries)  by  creating  a  “map”  of  users,  their  activities, 
and  the  Stories  (or  User  Stories)  needed  to  imple¬ 
ment  the  functionality  needed. 

™  Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14*’’  Edition,  July  201 1 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14*’’  Edition,  July  201 1 

Term  and  definition(s)  adapted  whole  or  in  part  from  http://www.agilelearninglabs.com/modules/story-mapping/ 
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Traditional  Terms:  Progressive  Elaboration 


Definition’'^^ 

Is  there  an  equivalent  in  the  Agile  World? 

Continuously  improving  and  detailing  a 
plan  as  more  detailed  and  specific  infor¬ 
mation  and  more  accurate  estimates  be¬ 
come  available  as  the  project  progresses, 
and  thereby  producing  more  accurate  and 
complete  plans  that  result  from  the  suc¬ 
cessive  iterations  of  the  planning  process. 

While  not  using  the  same  terminology,  this  concept  is  fundamental  to 
Agile  methods  and  underlies  the  five  levels  of  Agile  planning. 

How  is  it  used  in  the  Traditional  World? 

Are  there  any  related  terms  or  concepts? 

Progressive  Elaboration  concepts  can  be 
used  throughout  the  life  cycle  but  are  most 
used  during: 

•  Pre-Systems  Acquisition 

(Technology  Development) 

•  Systems  Acquisition  (Engineer¬ 
ing  and  Manufacturing  Deveiop- 
ment  and  Production  and  De- 
pioyment) 

•  Sustainment  (Operations  and 
Support) 

Rolling  Wave 
Planning 

Rolling  wave  planning  involves  planning  near-term 
work  in  the  greatest  detail  down  to  the  lowest  level 
of  the  WBS,  while  planning  the  mid-term  and  long¬ 
term  at  increasing  higher  levels  of  the  WBS. 

It  is  called  “rolling”  because  the  more-detailed  plan¬ 
ning  for  the  next  one-to-two  work  periods  is  done 
during  the  current  work  period  such  that  planning 
“rolls  forward”  along  with  the  project  schedule. 

Five  Levels  of 
Agile  Planning^'’"^ 
(Agite  Worid  def¬ 
inition) 

The  five  levels  of  Agile  planning  are: 

•  Vision  -  The  highest  level 

•  Roadmap  -  The  vision  distilled  into  a  high 
level  plan. 

•  Release  -  A  planning  segment  of  priori¬ 
tized  requirements  and  execution  esti¬ 
mates. 

•  Sprint  (or  Iteration)  -  A  predefined,  time- 
boxed  period  in  which  working  software  is 
created. 

•  Daily  Work  -  a  daily  communication  and 
planning  forum. 

Terms  and  definition{s)  adapted  whole  or  in  part  from  PMBOK  Guide®-  Third  Edition 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods]  http://www.aspe-sdlc.com 
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Traditional  Terms:  Prototype 


Definition’'^® 

Is  there  an  equivalent  in  the  Agile  World? 

A  model  or  preliminary  implementation  of 
a  piece  of  software  suitable  for  the  evalua¬ 
tion  of  system  design,  performance  or 
production  potential,  or  for  the  better  un¬ 
derstanding  of  the  software  requirements. 

This  term  means  approximately  the  same  in  the  Traditional  World  and 
Agile. 

How  is  it  used  in  the  Traditional  World? 

Are  there  any  related  terms  or  concepts? 

Prototypes  can  be  used  throughout  the  life 
cycle  but  are  most  used  during: 

•  Technology  Opportunities  and 
resources 

•  Pre-Systems  Acquisition  {Ma¬ 
terial  Solution  Analysis  and 
Technology  Development) 

•  Systems  Acquisition  {Engineer- 
ing  and  Manufacturing  Develop¬ 
ment) 

Risk-Based 

Spike 

(Agile  World  def¬ 
inition) 

A  spike  (a  small  iteration  or  experiment  to  research 
and  answer  a  problem)  driven  by  risk  considera¬ 
tions. 

Spike 

(Agile  World  def¬ 
inition) 

A  spike  is  a  small  iteration  or  experiment  to  re¬ 
search  and  answer  a  problem. 

Brassboard''’® 

An  experimental  device  to  determine  feasibility 
and/or  to  develop  technical  or  operational  data; 
normally  capable  of  being  used  in  the  field  and  may 
resemble  the  end  item  but  it  is  not  production 
ready. 

Breadboard'^'’ 

An  experimental  device  to  determine  feasibility 
and/or  to  develop  technical  or  operational  data; 
normally  only  used  in  a  lab,  it  may  not  resemble  the 
end  item  and  is  not  production  ready. 

Terms  and  definition{s)  adapted  whole  or  in  part  from  ISA/IEC/IEEE  24765  Systems  and  Software  Engineering 
-  Vocabulary,  December  15,  2010 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14*’’  Edition,  July  201 1 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14“’  Edition,  July  201 1 
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Traditional  Terms:  Requirements  Scrub 


Definition’'^® 

Is  there  an  equivalent  in  the  Agile  World? 

A  review  of  a  draft  requirements  for  ade¬ 
quacy  and  clarity;  may  also  include  re¬ 
viewing  comments  regarding  the  require¬ 
ments  to  validate  and  prioritize  the 
requirements. 

A  “requirements  scrub”  is  at  the  heart  of  Agile  planning  {backlog  pruning 
or  backlog  grooming):  it  is  done  when  clarifying  and  prioritizing  the 
product  backlog,  the  release  backlog,  the  sprint  (or  iteration)  backlog, 
and  (if  used)  the  daily  backlog. 

How  is  it  used  in  the  Traditional  World? 

Are  there  any  related  terms  or  concepts? 

In  a  true  Traditional  waterfall  program,  the 
requirements  scrub  is  done  during  user 
needs  as  part  of  the  requirements  pro¬ 
cess. 

Relative 

Prioritization'^® 

A  9-step  process  to  prioritize  requirements: 

•  List  the  requirements 

•  Estimate  the  relative  benefit  of  each  (1  to 

9) 

•  Estimate  the  relative  penalty  of  not  includ¬ 
ing  each  (1  to  9) 

•  Sum  2  and  3  (applying  weighting  is  op¬ 
tional) 

•  Estimate  the  relative  cost  to  build  (1  to  9) 

•  Estimate  the  relative  cost  to  implement  (1 
to  9) 

•  Estimate  the  relative  degree  of  technical 
risk  (1  to  9) 

•  Calculate  the  priority  number  (formulas 
vary) 

•  Sort  the  requirements  in  priority  order 

Backlog'®® 

(Agile  World  def¬ 
inition) 

The  backlog  is  a  prioritized  list  of  stories  (or  user 
stories)  and  defects  ordered  from  the  highest  priori¬ 
ty  to  the  lowest. 

Backlogs  include  both  functional  and  non-functional 
stories  (or  user  stories)  as  well  as  technical  team¬ 
generated  stories. 

™  Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14*’’  Edition,  July  201 1 

Term  and  definition(s)  adapted  whole  or  in  part  from  Agile  Glossary:  Words  and  Terms  Common  to  Agile  Meth¬ 
ods:  http://www.aspe-sdlc.com 

Term  and  definition(s)  adapted  whole  or  in  part  from  http://www.accurev.com/wiki/agile-glosssary 
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Traditional  Terms:  System  Specification 


Definition’'®’' 

Is  there  an  equivalent  in  the  Agile  World? 

A  description  of  the  system-level  require¬ 
ments,  constraints,  and  interfaces  (func¬ 
tional,  performance,  and  design)  along 
with  the  qualification  conditions  and  pro¬ 
cedures  for  their  testing  and  acceptance. 

Most  similar  to  the  Agile  epic,  though  perhaps  a  better  comparison 
would  be  to  a  group  of  epics. 

How  is  it  used  in  the  Traditional  World? 

Are  there  any  related  terms  or  concepts? 

In  a  true  Traditional  World  program,  the 
system  specification  is  initially  reviewed  at 
the  preliminary  design  review  and  is  ap¬ 
proved  at  the  critical  design  review. 

System'®^ 

1 )  The  organization  of  hardware,  software,  mate¬ 
rial,  facilities,  personnel,  data,  and  services 
needed  to  perform  a  designated  function  with 
specified  results,  such  as  the  gathering  of 
specified  data,  its  processing,  and  delivery  to 
users. 

2)  A  combination  of  two  or  more  interrelated  piec¬ 
es  of  equipment  (or  sets)  arranged  in  a  func¬ 
tional  package  to  perform  an  operational  func¬ 
tion  or  to  satisfy  a  requirement. 

Epics  or  Epic 
Stories 

(Agiie  Worid  def¬ 
inition) 

A  very  large  user  story — too  large  to  be  accurately 
estimated  or  completed  in  a  reasonably  number  of 
iterations. 

Epics  are  common  when  creating  the  initial  product 
backlog,  and  are  broken  down  into  smaller  stories 
(or  user  stories)  for  planning  and  execution. 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14*’’  Edition,  July  201 1 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14“’  Edition,  July  201 1 
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Traditional  Terms:  Tradit 

tional  Waterfall  Methods 

Definition 

Is  there  an  equivalent  in  the  Agile  World? 

A  plan-driven  software  development 
methodology  using  distinct  phases;  phas¬ 
es  are  performed  in  a  single-pass,  se¬ 
quential  order,  and  the  initiation  of  any 
subsequent  phase  requires  the  docu¬ 
mented  completion  of  the  previous  phase. 

The  notional  phases  are: 

•  Requirements  elicitation 

•  Requirements  analysis 

•  System  design 

•  System  construction 

•  System  test  and  integration 

•  System  operation 

•  System  retirement 

The  main  instantiations  are  the  original 
waterfall  paradigm  and  the  V-shaped  par¬ 
adigm. 

There  is  an  argument  that  an  Agile  sprint  (or  iteration)  is  a  mini¬ 
waterfall;  however  there  are  key  aspects  of  Agile  methods  not  present 
in  Traditional  waterfall  such  as: 

•  Continuous  integration 

•  Continuous  test 

•  Sustainable  pace 

•  Set  scope  and  budget 

•  Daily  meetings 

In  addition,  a  series  of  mini-waterfalls  does  not  allow  for  the  continuous 
reprioritization  of  requirements  to  be  addressed  in  each  mini-waterfall. 

How  is  it  used  in  the  Traditional  World? 

Are  there  any  related  terms  or  concepts? 

Incremental 

Approach^®^ 

Determines  user  needs  and  defines  the  overall  ar¬ 
chitecture,  but  then  delivers  the  system  in  a  series 
of  increments  or  builds  where  the  first  build  incorpo¬ 
rates  a  part  of  the  total  planned  capabilities,  the 
next  build  adds  more  capabilities,  and  so  on,  until 
the  entire  system  is  complete 

Evolutionary  Ac¬ 
quisition  (EA)''®'' 

Preferred  DoD  strategy  for  rapid  acquisition  of  ma¬ 
ture  technology  which  delivers  capability  in  incre¬ 
ments  while  recognizing  upfront  the  need  for  future 
capability  improvements;  each  increment  is  a  mili¬ 
tarily  useful  and  supportable  operational  capability 
that  can  be  developed,  produced,  deployed,  and 
sustained. 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14*’’  Edition,  July  201 1 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14“’  Edition,  July  201 1 
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Traditional  Terms:  Work  Breakdown  Structure  (WBS) 


Definition’*"® 

Is  there  an  equivalent  in  the  Agile  World? 

An  organized  method  to  break  down  a 
project  into  logical  subdivisions  or  subpro¬ 
jects  at  lower  and  lower  levels  of  details; 
very  useful  in  organizing  a  project. 

When  taken  in  their  total,  the  five  levels  of  agile  planning  (product  vi¬ 
sion,  product  roadmap,  release  plans,  sprint  (or  iteration)  plans,  and 
daily  commitments)  match  or  even  exceed  the  information  captured  in  a 
Traditional  World  WBS. 

A  WBS  can  also  be  associated  with  the  Scrum  teams  that  make  up  the 
Scrum  of  Scrums  on  a  larger  program. 

How  is  it  used  in  the  Traditional  World? 

Are  there  any  related  terms  or  concepts? 

A  WBS  is  used  to  organize  all  work  on  a 
Traditional  World  program. 

In  addition,  the  structure  of  the  WBS  tends 
to  match  the  structure  of  both  the  govern¬ 
ment  and  development  contractor  organi¬ 
zations  (and  vice  versa),  which  may  or 
may  not  improve  the  project’s  chances  for 
success. 

Organizational 
Breakdown 
Structure  (OBS) 

186 

A  hierarchical  depiction  of  an  organization  relating 
work  packages  to  the  organizational  units  perform¬ 
ing  the  work. 

Cost  Breakdown 
Structure''®^ 

A  system  for  subdividing  a  program  into  hardware 
elements  and  subelements,  functions  and  subfunc¬ 
tions,  and  cost  categories  to  provide  for  more  effec¬ 
tive  management  and  control  of  the  program. 

Contract  Work 
Breakdown 
Structure 
(CWBS)188 

A  complete  WBS  for  a  contract.  It  includes  the 
DoD-approved  program  WBS  extended  to  the 
agreed  contract  reporting  level  and  any  discretion¬ 
ary  extensions  to  lower  levels  for  reporting  or  other 
purposes.  It  includes  all  the  elements  for  the  prod¬ 
ucts  (hardware,  software,  data,  or  services)  that  are 
the  responsibility  of  the  contractor.  This  compre¬ 
hensive  WBS  forms  the  framework  for  the  contrac¬ 
tor’s  management  control  system. 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14“’  Edition,  July  201 1 

Terms  and  definition{s)  adapted  whole  or  in  part  from  PMBOK  Guide®-  Third  Edition 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14*“  Edition,  July  201 1 

Terms  and  definition{s)  adapted  whole  or  in  part  from  DAU  Glossary  of  Defense  Acquisition  Acronyms  and 
Terms,  14“’  Edition,  July  201 1 
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5  Summary 


The  Traditional  World  and  the  Agile  World  are  simply  two  instantiations  of  the  software  world. 

In  some  ways  they  are  related  by  cause  and  effect  since  the  Agile  Manifesto  and  related  methods 
grew  out  of  a  group  of  developers’  frustrations  with  the  “heaviness”  of  DoD’s  implementation  of 
waterfall,  which  had  itself  grown  out  of  the  need  for  rigor  to  address  a  “software  crisis.” 

Agile  methods  emphasize  structured,  multi-level  planning,  continuous  customer  involvement, 
frequent  (if  not  continuous)  test,  continuous  integration,  and  frequent  delivery  of  potentially  de¬ 
liverable  software.  As  such,  Agile  methods  can  be  argued  to  be  a  better  way  for  many  DoD  pro¬ 
jects  to  obtain  the  insight  and  control  wanted  when  DoD  imposed  many  of  its  current  practices. 
There  is  no  doubt  that  DoD  adoption  of  Agile  methods  will  require  significant  cultural  and  even 
perhaps  legal  (i.e.,  contracting)  changes.  However,  the  possibility  that  government  programs 
could  nimbly  respond  to  changing  environments  and  requirements  on  a  pace  measured  in  months 
instead  of  years  is  simply  too  good  of  a  future  to  ignore. 

We  have  tried  to  show,  though,  that  Agile  principles  are  not  foreign  to  software  development  in 
the  federal  government;  there  are  many  examples  of  Agile  or  even  eXtreme  development  efforts 
over  the  last  decades.  We  have  also  tried  to  show  the  both  the  Traditional  World  and  the  Agile 
World  use  the  same  fundamental  building  blocks  and  have  the  same  fundamental  goals. 

This  is  not  to  say  that  traditional  methods  are  the  same  as  Agile  methods.  They  are  not.  However, 
they  are  two  different  ways  to  perform  the  same  tasks — analyze,  design,  build,  test,  and  deploy.  In 
some  ways,  they  can  be  thought  of  as  parallel  worlds,  where  the  “what”  to  do  is  the  same  but  the 
“how”  to  do  it  is  different. 

Thus,  the  difference  is  in  perspective  and  application — and  words.  By  considering  the  similarities, 
the  goal  is  to  ease  fear  and  rejection  of  either  method  by  the  other  community.  By  no  means  have 
we  concluded  they  are  equivalent. 

We  deliberately  limited  this  paper  to  a  total  of  50  terms,  though  astute  readers  will  point  out  we 
included  dozens  more  in  the  “related  terms  and  concepts”  block.  We  were  surprised  as  we  began 
this  paper  that  this  type  of  Rosetta  Stone  didn’t  already  exist,  though  we  did  find  a  number  of 
smaller  efforts.'*® 

We  hope  this  technical  note  stimulates  discussions  among  practitioners  in  both  communities  and 
that  regular  revisions  can  be  made  to  this  report  so  that  terms  and  definitions  can  be  added,  updat¬ 
ed,  or  removed  as  needed. 

Even  more,  we  hope  that  this  technical  report  helps  facilitate  DoD’s  adoption  of  Agile  methods. 
We  hope  that  we  have  shown  that  the  two  worlds  are  not  as  far  apart  as  some  believe. 


However,  as  we  worked  on  the  paper  and  the  term  count  went  well  above  200  and  was  still  climbing — as  every 
term  seemed  to  require  two-to-three  more  in  its  definition — we  did  grasp  part  of  the  reason. 
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Appendix  A  Waterfall  Software  Development  -  DoD’s 
Misplaced  Emphasis? 


Despite  the  widely-held  view  that  the  waterfall  development  paradigm  is  DoD’s  and  the  federal 
government’s  “tradition,”  there  are  many  examples  where  federal  software  development  could 
rightly  be  called  Agile — even  extreme — long  before  these  terms  assumed  their  current  interpreta¬ 
tions. 

Larman  and  Basili  provide  several  examples  of  this,  starting  in  the  1960s  [Larman  2003].  Project 
Mercury  used  half-day,  time-boxed  iterations  and  practiced  test-first  development  for  each  micro¬ 
increment.  In  the  1970s,  the  Light  Airborne  Multipurpose  System  (LAMPS)  incrementally  deliv¬ 
ered  millions  of  lines  of  code  in  45  time-boxed  iterations  that  were  each  one  month  long.  Each  of 
the  LAMPS  iterations  was  delivered  on  time  and  under  budget. 

Also  in  the  1970s,  the  primary  avionics  software  for  the  space  shuttle  was  delivered  in  a  series  of 
1 7  iterations  over  3 1  months.  They  avoided  waterfall  (although  they  did  call  it  the  “ideal”  soft¬ 
ware  development  cycle)  because  the  requirements  were  not  stable.  Instead,  they  used  “. . .  an  im¬ 
plementation  approach  (based  on  small  incremental  releases)  . . .  which  met  the  objectives  by  ap¬ 
plying  the  ideal  cycle  to  small  elements  of  the  overall  software  package  on  an  iterative  basis.” 

While  not  mentioned  in  Larman  and  Basili’s  paper,  in  the  1970s  the  Department  of  Veteran  Af¬ 
fairs  made  colocation  a  primary  mechanism  for  the  VistA  system,  when  many  VistA  applications 
were  built  by  doctors  and/or  clinicians  working  side  by  side  with  a  programmer.  In  fact,  in  many 
cases  the  doctor  or  clinician  were  themselves  the  programmer  using  the  MUMPS  language  (Mas¬ 
sachusetts  General  Hospital  Utility  Multi-Programming  System). 

These  examples  and  more  indicate  that  many  people  in  the  federal  government  understood  the 
benefits  of  an  iterative,  incremental  approach.  Larman  and  Basili  also  show  that  many  people 
knew  that  what  was  to  become  known  as  a  “waterfall”  approach  would  not  work  for  large,  com¬ 
plex  systems.  For  example,  they  provide  a  quote  from  Gerald  Weinburg,  who  worked  on  Project 
Mercury:  “. . .  all  of  us,  as  far  as  I  can  remember,  thought  waterfalling  of  a  huge  project  was  rather 
stupid,  or  at  least  ignorant  of  the  realities  ...  I  think  what  the  waterfall  description  did  for  us  was 
make  us  realize  we  were  doing  something  else,  something  unnamed  except  for  ‘software  devel¬ 
opment.’” 

But  while  there  were  successes,  there  were  failures — so  much  that  by  the  late  1960s  it  was 
deemed  a  “software  crisis.”  The  NATO  Science  Committee  held  a  conference  in  1968  on  “soft¬ 
ware  engineering,”  apparently  the  first  time  this  term  was  used  and  “. . .  deliberately  chosen  as 
being  provocative,  in  implying  the  need  for  software  manufacture  to  be  based  on  the  types  of  the¬ 
oretical  foundations  and  practical  disciplines,  that  are  traditional  in  the  established  branches  of 
engineering”  [Naur  1969]. 

This  conference  focused  on  such  issues  as 

•  the  problems  of  achieving  sufficient  reliability  in  the  data  systems  which  are  becoming  in¬ 
creasingly  integrated  into  the  central  activities  of  modem  society 
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•  the  difficulties  of  meeting  schedules  and  specifications  on  large  software  projects 

•  the  education  of  software  (or  data  systems)  engineers 

•  the  highly  controversial  question  of  whether  software  should  be  priced  separately  from  hard¬ 
ware 

At  almost  the  same  time  (1970),  Dr.  Winston  Royce  published  Managing  the  Development  of 
Large  Software  Systems,  where  he  presented  what  he  were  his  “personal  views  about  managing 
large  software  developments”  [Royce  1970].  Though  Royce  never  used  the  term  “waterfall”  in  his 
paper  and  the  paper  is  in  fact  an  argument  for  iterative  development,  many  people  consider  his 
paper  as  the  basis  for  the  waterfall  development  methodology  to  the  point  where  he  has  been 
called  the  “father  of  waterfall.” 

Royce  began  his  paper  with  what  1  will  call  Royce  Model  #1,  which  he  felt  was  the  simplest  form 
of  a  software  development  process: 


Analysis 

Coding 

Figure  8:  Royce  Model  #1 

Royce  captioned  this  Implementation  steps  to  deliver  a  small  computer  program  for  internal  op¬ 
erations. 

Royce  said  Model  #1  was  potentially  acceptable  when  “. . .  the  effort  is  sufficiently  small  and  if 
the  final  product  is  to  be  operated  by  those  who  built  it — as  is  typically  done  with  computer  pro¬ 
grams  for  internal  use.”  Royce  then  described  Royce  Model  #2,  which  he  called  “more  grandi¬ 
ose:” 
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Figure  9:  Royce  Model  #2 

In  a  very  good  example  of  how  the  choice  of  words  can  have  an  impact  far  beyond  what  the  au¬ 
thor  perhaps  envisioned,  Royce  captioned  Model  #2  as  Implementation  steps  to  develop  a  large 
computer  program  for  delivery  to  a  customer. 

Had  a  reader  stopped  at  that  caption,  they  would  have  thought  Royce  just  described  his  recom¬ 
mended  approach  for  delivering  large  computer  programs,  though  a  complete  reading  of  his  paper 
would  have  dispelled  this.  Royce’s  paper  continued  with  the  addition  of  the  . .  iterative  relation¬ 
ship  between  successive  development  phases  for  this  scheme,”  or  Royce  Model  #3 : 
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Figure  1 0:  Royce  Model  #3 

But  even  while  Royce  said  that  he  believed  in  the  concept  of  Model  #3,  he  felt  that  even  this 
model  was  “risky  and  invites  failure”  (italics  added).  As  an  example,  he  pointed  out  that  with  test¬ 
ing  at  the  end  of  the  development  cycle,  issues  with  timing,  storage,  input/output  transfers,  and  the 
like,  are  not  discovered  until  a  major  redesign  is  invariably  required. 

Royce  observed:  “The  required  design  changes  are  likely  to  be  so  disruptive  that  the  software  re¬ 
quirements  upon  which  the  design  is  based  and  which  provides  the  rationale  for  everything  are 
violated.  Either  the  requirements  must  be  modified,  or  a  substantial  change  in  the  design  is  re¬ 
quired.  In  effect  the  development  process  has  returned  to  the  origin  and  one  can  expect  up  to  a 
100-percent  overrun  in  schedule  and/or  costs  (italics  added)”. 

Royce  devoted  the  remainder  of  his  paper  to  the  “. . .  five  additional  features  that  must  be  added  to 
this  basic  approach  to  eliminate  most  development  risks.”  These  included  his  recommendation 
that  this  model  be  run  at  least  twice  (iteratively),  with  the  first  time  being  a  significant  prototyping 
phase  that  was  used  to  better  understand  the  requirements,  better  understand  the  technologies  in¬ 
volved,  and  ensure  it  was  providing  what  the  customers  actually  needed. 

Royce  also  recommended  that  the  customer  be  involved  well  before  testing  as  “for  some  reason 
what  a  software  design  is  going  to  do  is  subject  to  wide  interpretation  even  after  previous  agree¬ 
ment”  (italics  added). 

As  stated  earlier,  Royce  never  used  the  term  waterfall  in  his  paper.  Again  quoting  from  Larman 
and  Basili,  Walker  Royce,  Dr.  Royce’s  son,  said  this  of  his  father  and  the  paper: 
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“He  was  always  a  proponent  of  iterative,  incremental,  evolutionary  development.  His  paper  de¬ 
scribed  the  waterfall  as  the  simplest  description,  but  that  it  would  not  work  for  all  but  the  most 
straightforward  projects.  The  rest  of  his  paper  describes  [iterative  practices]  within  the  context  of 
the  60s/70s  government  contracting  models  (a  serious  set  of  constraints)”  [Larman  2003]. 

But  the  federal  government’s  push  for  engineering  rigor  and  greater  control  settled  on  what  was 
now  known  as  “waterfall.”  Manifested  by  extensive  documentation,  a  strong  preference  for  a  sin¬ 
gle-pass,  sequential  development  method,  and  heavy  oversight,  the  waterfall  development  method 
was  perhaps  best  captured  in  DOD-STD  2167  (1985). 

However,  even  as  DOD-STD  2167  was  released,  the  document  itself  and  the  waterfall  method  it 
espoused  were  already  under  attack.  In  1986,  a  draft  copy  of  Revision  A  to  MIL-STD  2167  ap¬ 
peared  which  removed  the  emphasis  on  top-down  design  and  called  out  rapid  prototyping  as  an 
alternative  to  the  waterfall.  In  1987,  the  Defense  Science  Board  recommended  that  2167  be  re¬ 
vised  to  “  ...  to  remove  any  remaining  dependence  upon  the  assumptions  of  the  “waterfall”  model 
and  to  institutionalize  rapid  prototyping  and  incremental  developmenf’  [DSB  1987]. 

But  the  perception  that  waterfall  was  the  federal  government’s  preferred  development  approach 
had  become  firmly  embedded.  Federal  software  development  and  acquisition  still  retained  a 
strong  hardware-oriented,  waterfall  flavor,  as  was  argued  in  a  2010  report  issued  by  the  National 
Research  Council  [NRC  2010]: 

For  example,  the  terminology  used  to  describe  the  engineering  and  manu¬ 
facturing  development  phase  emphasizes  the  hardware  and  manufacturing 
focus  of  the  process  ...  Preliminary  design  reviews  (PDRs)  and  critical  de¬ 
sign  reviews  (CDRs),  hallmarks  of  the  waterfall  SDLC  model,  are  pre¬ 
scribed  for  every  program,  with  additional  formal  Milestone  Decision  Au¬ 
thority  (MDA)  decision  points  after  each  design  review.  At  least  four  and 
potentially  five  formal  MDA  reviews  and  decision  points  occur  in  every 
evolutionary  cycle. 

This  isn’t  to  say  that  traditional  waterfall  does  not  or  has  not  delivered  quality  products  that  are  in 
the  field  and  working  today — it  obviously  has.  However,  more  often  than  not  the  traditional  world 
has  delivered  quality  products  despite  waterfall,  not  because  of  waterfall. 

Continuing  to  quote  from  the  2010  National  Research  Council  report: 

As  a  result,  although  the  oversight  and  governance  process  of  DODl  5000 
does  not  forbid  the  iterative  incremental  software  development  model  with 
frequent  end-user  interaction,  it  requires  heroics  on  the  part  of  program 
managers  (PMs)  and  MDAs  to  apply  iterative,  incremental  development 
(IID)  successfully  within  the  DODI 5000 framework  (italics  added). 

Today,  many  of  the  DOD’s  large  IT  programs  therefore  continue  to  adopt 
program  structures  and  software  development  models  closely  resembling 
the  waterfall  model  rather  than  an  IID  model  with  frequent  end-user  inter¬ 
action.  Even  those  that  plan  multiple  delivered  increments  typically  at¬ 
tempt  to  compress  a  waterfall-like  model  within  each  increment. 
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So  if  the  premise  that  DOD-STD  2167  and  other  waterfall-based  standards  and  instructions  fun¬ 
damentally  misunderstood  Royce  could  be  accepted,  it  follows  that  DoD’s  multi-decade  emphasis 
on  waterfall  was  misplaced.  And  if  that  is  accepted,  one  can  only  wonder  what  DOD’s  current 
software  environment  would  be  like  if  2167  had  emphasized  DoD’s  “Agile  roots”  instead. 
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Appendix  B  History  of  Agiie^^^ 


For  additional  information,  please  see  these  other  SEI  Technical  Notes: 

•  Agile  Methods:  Selected  DoD  Management  and  Acquisition  Concerns',  CMU/SEI-20 1 1-TN- 
002 

•  Considerations  for  Using  Agile  in  DoD  Acquisition',  CMU/SEI-20  lO-TN-002 

In  many  ways  there  is  nothing  new  in  Agile.  As  we  showed  in  Appendix  A  there  were  a  number 
of  software  development  efforts  in  the  federal  government  that  were  agile  well  before  agile  be¬ 
came  a  well-known  term.  They  were  what  we  call  31 — inventive,  iterative,  and  incremental. 

What  is  new  about  Agile  is  how  these  “old”  components  are  combined  with  some  new  compo¬ 
nents  (ideas,  practices,  theories,  etc.)  to  yield  something  more  powerful  and  coherent.  However, 
as  Jim  Highsmith  asserts,  “the  Agile  approaches  scare  corporate  bureaucrats — at  least  those  that 
are  happy  with  pushing  process  for  process’  sake  versus  trying  to  do  what  is  best  for  the  ‘custom¬ 
er’  and  deliver  something  timely  and  tangible  ‘as  promised’ — ^because  they  run  out  of  places  to 
hide.”'‘^' 

This  coherence — ^and  the  current  energy  driving  advocacy  of  Agile — was  the  result  of  a  remarka¬ 
ble  meeting  among  thought  leaders  and  consultants'®^  in  software  development  who  would  nor¬ 
mally  have  been  competitors.  In  February  2001  17  people  met  to  try  to  find  common  ground  and 
ultimately  produced  the  Agile  Software  Development  Manifesto.  This  document  detailed  all  of 
their  commonalities — overlooking,  for  the  moment,  areas  where  they  had  differences  of  opinion. 

Agile  Manifesto  and  Principles 

The  self-named  Agile  Alliance  shared  allegiance  to  a  set  of  compatible  values  promoting  organi¬ 
zational  models  based  on  people,  collaboration,  and  building  organizational  communities  compat¬ 
ible  with  their  vision  and  principles.'®^ 

From  the  manifesto: 

We  are  uncovering  better  ways  of  developing  software  by  doing  it  and  helping 
others  do  it.  Through  this  work  we  have  come  to  value: 

•  Individuals  and  interactions  over  processes  and  tools 

•  Working  software  over  comprehensive  documentation 


This  section  draws  extensively  from  the  SEI  technical  note,  Considerations  for  Using  Agile  in  DOD  Acquisition. 
http://agilemanifesto.org/history.html 

The  signatories  were  representatives  from  Extreme  Programming,  SCRUM,  DSDM,  Adaptive  Software  Devel¬ 
opment,  Crystal,  Feature-Driven  Development,  Pragmatic  Programming,  and  others:  Kent  Beck,  Mike  Beedle, 
Arie  van  Bennekum,  Alistair  Cockburn,  Ward  Cunningham,  Martin  Fowler,  James  Grenning,  Jim  Flighsmith,  An¬ 
drew  Flunt,  Ron  Jeffries,  Jon  Kern,  Brian  Marick,  Robert  C.  Martin,  Steve  Mellor,  Ken  Schwaber,  Jeff  Suther¬ 
land,  Dave  Thomas. 

http://agilemanifesto.org/history.html 
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•  Customer  collaboration  over  contract  negotiation 

•  Responding  to  change  over  following  a  plan 

That  is,  while  there  is  value  in  the  items  on  the  right,  we  value  the  items  on  the 
left  more. 

As  the  Agile  Alliance  noted,  the  four  dichotomies  listed  in  the  manifesto  (such  as  “individuals  and 
interactions  over  processes  and  tools”)  are  not  intended  to  suggest  that  what  is  on  the  left  is  im¬ 
portant  and  what  is  on  the  right  is  unimportant;  rather,  what  is  on  the  right,  while  important,  is 
simply  less  important  than  what  is  on  the  left. 

For  example,  some  believe  that  the  Agile  approach  advocates  providing  no  documentation  other 
than  the  code  itself  The  Agile  community  would  argue  instead  that  documentation  is  important, 
but  no  more  documentation  should  be  created  than  is  absolutely  necessary  to  support  the  devel¬ 
opment  itself  and  future  sustainment  activities.  In  fact,  Agile  emphasizes  collaboration  and  the 
notion  that  when  documentation  replaces  collaboration  the  results  are  problematic.  Documenta¬ 
tion  should  be  the  result  of  collaboration. 

The  Agile  Alliance  says  the  following  12  principles  underlie  the  Agile  Manifesto: 

•  Our  highest  priority  is  to  satisfy  the  customer  through  early  and  continuous  delivery  of  valua¬ 
ble  software. 

•  Welcome  changing  requirements,  even  late  in  development.  Agile  processes  harness  change 
for  the  customer's  competitive  advantage. 

•  Deliver  working  software  frequently,  from  a  couple  of  weeks  to  a  couple  of  months,  with  a 
preference  to  the  shorter  timescale. 

•  Business  people  and  developers  must  work  together  daily  throughout  the  project. 

•  Build  projects  around  motivated  individuals.  Give  them  the  environment  and  support  they 
need,  and  trust  them  to  get  the  job  done. 

•  The  most  efficient  and  effective  method  of  conveying  information  to  and  within  a  develop¬ 
ment  team  is  face-to-face  conversation. 

•  Working  software  is  the  primary  measure  of  progress. 

•  Agile  processes  promote  sustainable  development.  The  sponsors,  developers,  and  users 
should  be  able  to  maintain  a  constant  pace  indefinitely. 

•  Continuous  attention  to  technical  excellence  and  good  design  enhances  agility. 

•  Simplicity — the  art  of  maximizing  the  amount  of  work  not  done — is  essential. 

•  The  best  architectures,  requirements,  and  designs  emerge  from  self-organizing  teams. 

•  At  regular  intervals,  the  team  reflects  on  how  to  become  more  effective,  then  tunes  and  ad¬ 
justs  its  behavior  accordingly.'®"* 

From  these  principles,  it  is  understood  that  Agile  is  really  a  philosophy  or  development  approach, 
and  it  comprises  a  number  of  more  specific  methods,  for  example,  eXtreme  programming  (XP), 
Scrum,  and  Adaptive  Software  Development  (ASD). 

http://agilemanifesto.org/principles.html 
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